Wir haben mit dem Stream Monitor regelmäßig das Problem, dass die META Daten von Input Stream überhaupt nicht übertragen werden. Tritt der Fehler einmal auf, scheint dieser Status hängen zu bleiben. Ich habe noch nicht ganz raus ob durch komplettes disconnecten aller Input-Streams ein Reset erfolgt oder ob das mein händisches eingreifen am Stream Monitor selber gewesen ist.
Könnte vielleicht auch mit dem Phänomen des Log-Fluten zusammenhängen.
Das Problem gibt es schon sehr lange. Auch ein erneutes Senden der Metadaten (sogar etwas abgewandelt) bringt überhaupt nichts. Manchmal muss man dann leider das ganze Programm neu starten, was im Livebetrieb nicht wirklich praktisch ist. Auch verschluckt der Streammonitor generell die Metadaten des ersten Tracks wenn man live geht. Ich habe zwar dafür ein Workaround gefunden, ist aber nicht wirklich schön!
Es reicht, wenn Du den betreffenden Stream Monitor deaktivierst und wieder aktivierst, man muss nicht das ganzen Programm beenden. Schön ist es trotzdem nicht, weil ich dazu händisch auf dem Server eingreifen muss und trotzdem Aussetzer im Streamsignal entstehen.
Ich habe 2 Stream Monitore eingerichtet während der erste keine Metadaten mehr übermittelt hat lief der 2. mit höherer Prio, normal weiter. Schätze aber nicht, dass es was mit der Prio zu tun hat.
Uns bleibt leider nichts anderes übrig als mit dem Fehler jetzt in den Live-Betrieb zu gehen, nach der mAirlist Anschaffung und dem neuen Server, fressen uns die Kosten langsam auf.
Wie sieht es denn mit diesem Problem aus?
Ich wollte erstmal dein Feedback zum Thema “Stream Monitor flutet Log” abwarten: https://www.mairlist.com/forum/index.php/topic,9226.0.html
Kannst du ausschließen, dass da ein Zusammenhang besteht bzw. bestand?
Hmm, das kann ich nicht ausschließen und wo ich noch mal drüber nachdenke, der Fehler ist mir in letzter Zeit nicht mehr aufgefallen.
Der Server ist jetzt im scharfen Betrieb, es finden also täglich Live-Sendungen statt. Wenn der Fehler wieder auftritt, werden ich es also jetzt zeitnah mitbekommen.
Was mir auch noch eingefallen ist, passt vielleicht auch zu beiden Phänomenen.
Ich hatte mit meinen Settings in mAirlist (2 Stream Monitore im Sekundentakt) und dem Default Windows TCP Connections Handling, den vServer an Sein I/O Limit gebracht.
Bei knapp 500 Connections ging der in die Knie obwohl es da in Windows 2016 eigentlich kein Limit mehr gibt (und der host angeblich vor sich hin idlet).
Danach habe ich mich ans Tuning gemacht, die Konfiguration steht ja hier:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\ParametersFrüher (Win7 /2008) gab es ja mal das Problem, dass Windows nur 10 Connections wollte und man musste das immer auf einen sinnvollen Wert tweaken. Das ist ja nun zum Glück nicht mehr zwingend erforderlich.
Was man aber noch tunen kann, ist das Time-Out für beendete oder abgebrochene Verbindungen. Das habe ich runter gesetzt. Dadurch habe ich die offenen TCP Connections auf unter 200 gedrückt, im live Betrieb, wenn nur noch ein Stream Monitor pollt, unter 100 Connections.
Die Änderung könnte auf beides passen.
These: Die META Updates konnten nicht mehr durchgeführt werden, weil Antwort zu langsam oder keine TCP Connection möglich, was dazu führt, dass sich der META Part vom Stream Monitor aufhängt. Sofern das wirklich kein Bug ist könnte man hier höchstens eine Erkennung einbauen und die Komponenten sich selber resetten lassen, als zusätzliches Feature für Betriebssicherheit.
Beim Fluten des Logs war es ja ähnlich, die Meldung sah so aus, ich habe kein Signal mehr, versuche aber die Verbindung zu halten. Was durch das kürzere TCP-Timout, jetzt nicht mehr passiert oder die Anfragen hatten durch zu viele TCP Connections, eine zu hohe Latenz, was zu dem Phänomen geführt hat.
Ich habe schon mal angefangen eine Virtual Box zu bauen, in der ich versuche alles vom Server nachzubilden. Da müsste man sowas ja provozieren können, ich habe hier einen gut ausgestatteten PC aber keine High End Kiste, also vermutlich genau passend und das Virtual Box Image müsste man 1:1 auf einen anderen Host übertragen können.
EDIT: Quelle für die Registry Hacks: https://kb.globalscape.com/KnowledgebaseArticle10438.aspx
Aber warum sollte der Stream-Monitor so viele offene Verbindungen erzeugen?
Eigentlich doch nur genau eine pro Eintrag. Und selbst die sollte nur längere Zeit “offen” sein, wenn der Stream auch erreichbar ist. Ansonsten meldet der Icecast-Server “Stream ist nicht da”, und die Verbindung wird wieder geschlossen.
Das ist alles in BASS_StreamCreateURL gekapselt. Ich wüsste nicht, was ich da falsch machen könnte.
Es sieht für mich so aus, als würde die Verbindung eben nicht beendet, sondern abgebrochen. Daher greift dann das Time-Out vom OS und schließt die Connection.
Weißt du zufällig, wie man mit Wireshark umgeht?
Ja, grob. Was brauchst Du?
Einfach mal einen kurzen Mitschnitt (pcap-Datei), wo man die Verbindungsversuche sehen kann.
OK, kann etwas dauern. Wir hatten heute (mal wieder) einen Servercrash, ich bin gerade froh dass alles wieder läuft.
Ich werde mit dem ganzen Klimbim wohl noch mal auf einen anderen Server umziehen müssen.
Nächste Woche müsste ich die Daten sammeln können.
Seit dem ich Icecast Umgestellt habe auf UTF-8, siehe https://www.mairlist.com/forum/index.php/topic,9191.msg61075.html#msg61075 , habe ich “gefühlt” häufiger das Problem, dass sich die META Sektion vom Stream Monitor weg schießt. Ich hatte das einmal am Freitag (08.09.17) und noch mal am Sonntag (17.09.17).
Es hat also scheinbar doch nichts mit der Virtualisierung zu tun oder zumindest nicht mit der Anzahl der TCP Connections. Erst mal nur als weitere Info.
Als Workaround würde ich gerne erst mal das Thema hier noch mal aufgreifen.
https://www.mairlist.com/forum/index.php/topic,9200.0.html