Moin Torben,
ich glaube nach Deinem Urlaub wartet reichlich Bug-Fixing.
Mein aktuelles Problem, sieht ähnlich aus, wie die ursprünglich falsche Konfiguration.
Ich dachte auch, dass die Änderung in Build 3587
[-] Stream playback always using infinite timeout when playing through DirectSound; also affects Stream Monitor which does not detect a stream going offline but waits for reconnect
Damit zusammen hängt aber es ist wohl noch nicht komplett gelöst.
Folgender Aufbau ich habe 2 Icecast Mounts, die im Sekundentakt abgefragt werden und die per http://127.0.0.1 abgefragt werden.
/live1 hat Prio 15
/live2 hat Prio 10
Priorisierung funktioniert auch so weit. Wenn ich von /live1 nach /live2 übergebe funktioniert die durchschaltung wenn danach aber /live1 getrennt wird, das verlorene Signal angezeigt, mAirList wertet den aber nicht als Off-AIR sondern versucht weiterhin, die Verbindung zu halten und flutet das Log. (klar bei 1 Sekunde Anfrage)
Wenn nun /live2 auch disconnected und die Automation wieder starten soll, werden beide Monitore zurückgesetzt und nehmen den korrekten Off-AIR Status an und die Automation startet auch, so wie ich es konfiguriert habe.
Im Grunde kann man damit senden aber ist natürlich unschön und wer weiß ob das noch andere Probleme nach sich zieht.
Ich bin nun aus dem Urlaub zurück und hatte etwas Zeit mir die Sache anzusehen. Allerdings konnte ich den Fehler bislang nicht reproduzieren.
Mein Test-Setup: Icecast mit zwei Streams /stream1 und /stream2, diese sind (mit Prio 1 und 2) im Stream-Monitor eingetragen und werden jeweils mit ezstream mit einer langen MP3-Datei (Sendungsmitschnitt) befeuert.
Ich habe verschiedene Szenarien durchgetestet, die Streams abwechselnd gestoppt und wieder gestartet - alles verhielt sich wie erwartet, der Stream-Monitor hat sofort “off air” angezeigt, wenn ein Stream nicht mehr verfügbar war, dazu die (einzelne) Meldung “Verbindung verloren” im Systemprotokoll.
Du sagst also, du siehst auch mit Build 3587 noch Meldungen der Art “Fehler beim Wiederverbinden…” im Log? Das finde ich sehr, sehr verwunderlich. Diese Meldungen erscheinen nämlich nur dann, wenn mit Streams hantiert wird, die einen Reconnect-Timeout eingestellt haben, entweder 0 (ewig probieren) oder einen Wert in Sekunden.
Das ist dieselbe Einstellung, die du auch in den Eigenschaften von Stream-Elementen in der Playlist siehst; intern verwendet der Stream-Monitor nämlich genau solche Stream-Elemente, allerdings immer mit Timeout -1, der bedeutet: Bei verlorender Verbindung sofort auf “EOF” springen, was der Stream-Monitor dann mit dem Status “off air” quittiert.
Ist das Problem bei dir mit Build 3587 definitiv zu reproduzieren? Dann bleibt uns nicht viel anderes übrig, als es mal auf eurer Maschine zu debuggen. Oder noch besser, auf meiner Maschine, aber mit eurem Setup und euren Streams. Dazu müsstest du mir natürlich irgendwie Zugriff auf die Moderatoren-Streams geben.
Hi Torben,
danke für das Feedback. Ich würde sagen, ich versuche dann erst noch mal, das auf einem anderen System nachzustellen. So langsam habe ich das Gefühl dieser Server hat ein ernsthaftes Performance Problem. Auch dieser Fehler passt, nach Deiner Beschreibung, so in etwa in diese Richtung. Ich habe irgendwie das Gefühl, da entstehen irgendwo Latenzen, die sich auch auf die Prozesse durchschlagen. Bei knapp 500 TCP handles, hat er keine mehr angenommen und ich musste ein Registry Hack anwenden um die Timouts abgebrochener Connections herunterzusetzen.
Wie sich inzwischen herausgestellt hat, wird dieser Server nun doch eine Übergangslösung, weil mir ein paar Features fehlen, muss jetzt aber erst mal live gehen.
Zukünftig werde ich meine eigene Virtualisierung hosten, vermutlich ein Proxmox. Das ist dann zwar die gleiche Virtualisierungstechnik (KVM), wie jetzt bei unserem Hoster (Parallels) aber ich habe sämtliche Ressourcen unter eigener Kontrolle.
Die nächsten gut 2 Wochen bin ich noch ziemlich ausgebucht, danach baue ich mein System mal als VM nach, die ich Dir ggf. schicken könnte. Hättest Du eine bevorzugte Virtualisierung, die Du vielleicht sowieso schon benutzt?
Ich kann das als KVM in Proxmox bauen, als Virtual Box oder Hyper-V.
Randnotitz für andere User: Windows 2016 Server ist nicht geeignet um mAirList im Nonstop Betrieb darauf laufen zu lassen. Ich musste gerade schmerzlich lernen, dass es auch da Feature-Upgrades wie unter Win10 gibt, die dazu führen, dass sich der Hardware Hash ändert und die mAirList Lizenz reaktiviert werden muss.
Und auch da hat man den Updatezeitpunkt, nicht unbedingt in der eigenen Hand. Ich gehe zurück auf Win8.1, 2012R2 wäre als Server eine Alternative.
Wir haben seit ein paar Wochen Mairlist auf Windows Server 2016 im dauer Live Betrieb zu laufen und ich konnte bis heute keine Probleme feststellen.
Da irgendwann mal Betriebssysteme wie Win 7,8 oder Windows Server 2012 etc. obsolet sein werden, wird man wohl zwangsläufig auf neue Systeme migrieren müssen.
Hier sollte sich dann aber auch Mairlist - was die “Feature-Upgrades” betrifft, irgendwie anpassen müssen.
[quote=“Bernd O., post:4, topic:11158”]Wir haben seit ein paar Wochen Mairlist auf Windows Server 2016 im dauer Live Betrieb zu laufen und ich konnte bis heute keine Probleme feststellen.
Da irgendwann mal Betriebssysteme wie Win 7,8 oder Windows Server 2012 etc. obsolet sein werden, wird man wohl zwangsläufig auf neue Systeme migrieren müssen.
Hier sollte sich dann aber auch Mairlist - was die “Feature-Upgrades” betrifft, irgendwie anpassen müssen.[/quote]
Das war auch mein Ursprünglicher Ansatz, gleich auf das neueste OS zu gehen, wenn Du einen Hardware Dongle benutzt, wirst Du auch um die Neuaktivierung herum kommen. Ansonsten hast Du ca. alle 3 Monate Dead-AIR auf dem Sender, weil der Hardware Hash, sich geändert hat. Da kann Torben in mAirlist auch nichts anpassen, die Ursache liegt bei Microsoft.
Siehe auch meine Ausführungen hier: https://www.mairlist.com/forum/index.php/topic,9230.msg60896.html#msg60896 Da ging es aber eher um Soundkarten IDs, im Prinziep aber die gleiche Ursache. Der Upgrade Zwang von Microsoft.
In den nächsten 6 Jahren, wird sicherlich eine Menge passieren und für mich reicht das erst mal, wenn ich bis dahin Ruhe habe, auf meinem Win8.1. Sicherheitsupdates bekomme ich jedenfalls bis dahin.
Also ein “Dead-AIR” würdest du zwangsläufig auch bei einem Neustart der Windows Kiste haben, wenn diverse Sicherheitsupdates etc. eingespielt werden müssen.
Richtig Dead-AIR aber nur für den Zeitraum des Neustarts, läuft die Lizenz ab, muss ich händisch eingreifen und so lange läuft nichts. Dazu kommt noch, dass ich den Zeitpunkt des Neustarts bei Win10/2016, nicht mehr exakt selber bestimmen kann. Ich kann nur einen Nutzungszeitraum festlegen, der maximal 12 Stunden lang ist. Irgendwann in den restlichen 12 Stunden des Tages, startet das System dann automatisch neu, ohne dass ich etwas dagegen machen kann. Ich kann das Update Prozedere also nicht richtig Monitoren.
Wenn ich den Zeitraum selber festlegen könnte, dann habe ich für diesen Zeitraum eine alternative Einspeisung.
Also beim Windows Server 2016 kann ich definitiv selbst festlegen, wie und ob Neustarts zu erfolgen haben.
Feature Updates kann man übrigens auch deaktivieren.
[quote=“Bernd O., post:8, topic:11158”]Also beim Windows Server 2016 kann ich definitiv selbst festlegen, wie und ob Neustarts zu erfolgen haben.
Feature Updates kann man übrigens auch deaktivieren.[/quote]
Ich werde zwar trotzdem umsteigen aber ich lerne auch gerne dazu. Wo geht das?
Das Feature Upgrade hat mir mein Provider ungefragt eingespielt, auf dem Hostsystem und anscheinend schlägt sich das auf meine VM durch.
Erstaunlich, ich habe keine Ahnung, was plötzlich anders ist aber die Flut im Log ist im Moment nicht mehr vorhanden.
Es gab lediglich ein OS Update/ Upgrade durch unseren Hoster. Ich behalte das mal weiter im Auge.