Media Server Dienst friert vollständig ein wenn Hintergrund-EPG-Update über SAT>IP-Gerät fehlschlägt

[klangraum23 0]

Hallo,

 

seit neuestem habe ich meine mit DVB Media Server betriebene Empängerlandschaft erweitert und nutze nun einen DVB-T2 USB-Stick und einen externen SAT>IP-Router. Das funktioniert im Prinzip großartig, bis auf ein gelegentlich auftretendes vollständiges Einfrieren des Media Server Dienstes, wenn der SAT>IP-Router ausgeschaltet ist. Nach Blick ins Server-Log habe ich nun ein zuverlässiges Repro-Szenario erstellen können:

 

1. DVB Media Server für die Verwendung eines SAT>IP-Routers (und einem anderen lokalen Empfangsgerät) einrichten.
2. SAT>IP-Gerät ausschalten oder vom Netzwerk trennen.
3. Ein Programm des lokalen Empfangsgeräts im Browser wiedergeben (Transkodierte Streams -> Im Browser wiedergeben)
4. In der Media Server Web-Oberfläche unter Aufgaben "EPG-Aktualisierung starten" anklicken
5. Der Service reagiert nicht mehr. Die Web-Oberfäche reagiert nicht mehr, der laufende HTTP-Stream bricht ab und der Dienst kann nicht mehr heruntergefahren werden. Der Prozess kann nur noch im Task Manager beendet werden.

 

Einfach nicht auf den Link klicken, wenn das SAP>IP-Gerät nicht eingeschaltet ist, ist leider keine Lösung, da das Problem auch auftritt, wenn der Media Server von sich aus versucht, die EPG-Daten zu aktualisieren. Aufnahmen sind in dieser Konstellation nicht mehr zuverlässig zu realisieren. Darüberhinaus habe ich den Eindruck, dass laufende HTTP-Streams abgebrochen werden, wenn weitere Hintergrundoperationen (z. B. das Öffnen eines zweiten HTTP-Streams oder eben das EPG-Update) gestartet werden - vielleicht gibt es da einen Zusammenhang.

 

Ich wollte eigentlich noch ein Dump-File des Dienstes im eingefrorenen Zustand mitschicken, das ist mit 42 MB aber leider zu groß. Bei Bedarf stelle ich die Datei gerne über einen anderen Kanal zur Verfügung. Bei Rückfragen stehe ich gerne zur Verfügung.

 

Jürgen

support.zip

[Griga 592]

Ich vermute, der DMS friert nicht wirklich ein (zumindest nicht bei den momentanen Temperaturen). Der tut nur so Wenn du lange genug warten würdest, wäre er vielleicht wieder ansprechbar.

 

Wahrscheinlich sind es recht viele Sender/Frequenzen, die du über den Sat>IP-Server empfängst. Ursache dürfte sein, dass der EPG-Updater immer wieder versucht, über das virtuelle RTSP-Gerät eine Frequenz einzustellen und immer wieder etwa vier Sekunden auf eine Antwort des Servers wartet. Und das ohne Pause. Man kann das schön am Ende des svcdebug.log sehen. Während der Wartezeit ist der DMS nicht reaktionsfähig bzw. kann nichts anderes erledigen. Nur eine Aufnahme würde wahrscheinlich ungestört weiterlaufen.

 

Was passieren müsste: Wenn der EPG-Updater einmal festgestellt hat, dass der Sat>IP-Server nicht erreichbar ist, müsste er sofort aufgeben und das dazugehörige RTSP-Gerät während des Durchlaufs nicht mehr verwenden. Das würde den DMS nur 4 Sekunden lang aus dem Verkehr ziehen.

 

Ich werde die Situation mal nachstellen und schauen, ob sich dafür eine Lösung findet. Falls ja, brauche ich dich als Tester. Also bitte hier gelegentlich vorbeischauen.

 

Übrigens sehe ich bei dir noch ein anderes Problem, ein Relikt eines früheren Bugs in der Hardware-Erkennung. Stoppe den DMS, öffne die Datei config\svchardware.xml im Konfigurationsordner mit einem Texteditor und werfe die beiden Zeilen

 

<entry name="LowBandWidth">1</entry>

 

raus. Sonst kannst du pro DVB-T2-Tuner nur jeweils einen TV-Sender gleichzeitig empfangen, oder anders gesagt, brauchst du z.B. für das Erste und arte unnötigerweise beide Tuner, obwohl die Sender über die selbe Frequenz übertragen werden.

 

[Griga 592]

P.S. Entschärfen kann man die Situation eventuell, indem man DMSTweaker.bat im Installationsordner startet und den Haken bei "Automatische RTSP Server IP:Port-Ermittlung" entfernt.

 

Nachdem er festgestellt hat, dass der Sat>IP Server nicht erreichbar ist, versucht der DMS sonst nämlich bei jeder Frequenz erneut, ihn im Netz wiederzufinden, unter der Annahme, dass sich vielleicht die IP-Adresse oder der Port geändert hat. Das zieht sich dann zusätzlich 5 Sekunden hin.

 

[klangraum23 0]

Vielen Dank für die schnelle Antwort und auch vielen Dank für den LowBandWidth-Hinweis, die Einschränkung ist mir bislang gar nicht aufgefallen.

 

Zum eigentlichen Problem:  Ich habe die "Automatische RTSP Server IP:Port-Ermittlung" deaktiviert und das Problem nochmal provoziert. Es tatsächlich so wie vermutet, der Dienst reagiert nur vorrübergehend nicht, wobei "vorrübergehend" jetzt immer noch ca. 5 Minuten bedeutet.

 

Der Lösungsansatz der Vermeidung der weiteren Anfragen an das RTSP-Gerät erscheint mir plausibel und es wäre sicher kein Problem, wenn das Web-Interface des DMS alle 12 Stunden für 4 bzw. 9 Sekunden nicht erreichbar wäre. Ich fürchte nur, dass das noch nicht die ganze Lösung ist, denn es brechen ja auch während dessen laufende HTTP-Streams ab. Warum muss der DMS denn komplett blockieren, während im Hintergrund ein Web-Zugriff gemacht wird? Es müsste intern doch nur der Zugriff auf die EPG-Datenhaltung synchronisiert werden, nicht aber der gesamte Zugriff auf die Hardware. Und beim HTTP-Streaming verstehe ich es erst recht nicht, aber ich bin auch nicht unbedingt ein Experte für Echtzeitdatenverarbeitung. :-)

 

Wenn es etwas zu testen gibt, kann ich das gerne hier in meiner Umgebung ausprobieren.

[Griga 592]

Wenn sich das so einfach ändern ließe, wie du es darstellst, wäre es schon längst anders.

 

Ich kümmere mich drum.

[klangraum23 0]

Entschuldige, ich wollte Dir nicht zu nahe treten, war nur laut gedacht. Mir ist klar, dass die Dinge von innen betrachtet ein vielfaches komplizierter sind als es manchmal von außen erscheint.

[Griga 592]

 

15 hours ago, klangraum23 said:

Es tatsächlich so wie vermutet, der Dienst reagiert nur vorrübergehend nicht, wobei "vorrübergehend" jetzt immer noch ca. 5 Minuten bedeutet.

 

Eine weitere mögliche Maßnahme ist die Verringerung des Verbindungs-Timeouts für das RTSP-Gerät. Es steht in der (svc)hardware.xml als ConnectionTimeout (standardmäßig 2000 Millisekunden). Effektiv wird die doppelte Zeit verwendet. Dass man in einem Heimnetzwerk 4000 ms auf eine Serverantwort warten muss, halte ich für zweifelhaft. Eine Halbierung des Wertes in der (svc)hardware.xml auf 1000 (effektiv 2000) sollte es auch tun. Im DVBViewer GE und TransEdit verwende ich standardmäßig den halbierten Wert und habe noch nie von einem Problem damit gehört.

 

Weiterhin ist es bei EPG Updates eine gute Idee, alle Sender, die einem wichtig sind, auf dem Server-PC in die DVBViewer-Favoritenliste zu packen und dann in den DMS-Optionen oder im Webinterface einen Haken bei "EPG Update -> Nur Transponder mit Favoriten" zu setzen. Das spart insbesondere bei Sat-Empfang eine Menge Ausführungszeit und Speicher. Zu beachten ist, dass der DMS Sender und Favoriten erst nach einem Neustart übernimmt und wenn sie zuvor im DVBViewer gespeichert wurden (oder der DVBViewer beendet wurde).

 

Damit könntest du unter eine Minute kommen. Aber immer noch unschön. Deshalb habe ich die oben angedachte Maßnahme umgesetzt: Der EPG Updater verwendet jetzt virtuelle und sonstige Geräte, bei denen die Initialisierung scheitert, während einer Update-Session nicht mehr.

 

Ein ähnliches Problem ist mir beim Recorder aufgefallen. Der versucht auch wiederholt, Aufnahmen zu starten, falls das nicht klappt. Da die Wiederholungen timergesteuert stattfinden und nicht in einer "engen" Schleife, reagiert der DMS dann noch, wenn auch ziemlich lahm. Ich habe jetzt dafür gesorgt, dass nur einmal pro Minute versucht wird, das betreffende Gerät wiederzubeleben.

 

Für einen Test siehe PM.