Jump to content

DMS startet Stream nicht - manchmal nach Neustart


carmen.vvl

Recommended Posts

Hallo, dieses Verhalten beobachte ich schon lange über diverse Versionen des DMS, Windows- und Treiber-Updates hinweg:

Nach einem Server-Neustart 'spricht' der DMS nicht mit meiner SAT>IP-Box, der lokale DVBViewer sagt, das kein Gerät verfügbar ist. Andere Geräte im Netz können (direkt vom SAT>IP) jedoch empfangen. Nach einem weiteren Server-Reboot geht es dann wieder, auch dauerhaft, so dass ich mich nicht weiter gekümmert habe.

 

Jetzt passierte es wieder und ich habe mal den Wireshark angeworfen - und nein, es ist nicht die Firewall oder Hardware oder sonstwas - sie kommunizieren, aber der DMS beendet nach dem 'RTSP/1.0 200 OK' mit [FIN, ACK] die Verbindung, um dann gleich wieder eine aufzubauen. In den Screenshots habe ich die Stellen markiert, wenn der DMS mit 'SETUP rtsp://...' fortfährt, funktioniert alles.

 

Wenn ich mich richtig erinnere, habe ich auch schon versucht, nur den DMS (über das Tray Icon) neu zu starten, was aber nicht zum Erfolg führte - vielleicht aber nur, weil der Dienst sehr lange zum Beenden braucht - was man am Icon nicht erkennen kann.

 

2019-06-12 11_46_10-192.168.17.20 - Remotedesktopverbindung.png

 

2019-06-12 11_47_01-192.168.17.20 - Remotedesktopverbindung.png

 

.20 ist der Server, .14 die SAT>IP Box, die Time-Spalte zeigt die Zeit zwischen den Paketen.

 

Edited by carmen.vvl
Link to comment

Wie sieht das Setup genau aus? Eine ominöse Sat>IP-Box (welche genau) als RTSP Server beliefert den DMS als Client. Habe ich das soweit richtig verstanden?

 

Aber wessen Client ist dann der DVBViewer?

 

7 hours ago, carmen.vvl said:

sie kommunizieren, aber der DMS beendet nach dem 'RTSP/1.0 200 OK' mit [FIN, ACK] die Verbindung,

 

IMO ist das ein normaler Vorgang. OPTIONS wird vom Client gesendet, um festzustellen, ob der Server da ist und antwortet, oder um eine Session durch regelmäßiges Sich-Melden am Leben zu erhalten. Die Sat>IP-Spezifikationen lassen dem Client die Wahl, ob er für jede RTSP Request eine neue Verbindung aufbaut oder sie bestehen lässt:

 

Quote

The RTSP control channel in  SAT>IP must be implemented using TCP. It is  important to note that RTSP sessions are independent of the underlying TCP connections.  
An  RTSP  session  generally  spans  multiple  TCP  connections  (e.g.  one  TCP  connection  per request-response). It is however also possible for an RTSP session to consist of a single TCP connection (persistent mode) including several RTSP request-response pairs. 

 

Link to comment

O.k., nochmal von vorn: Die SAT>IP Box ist eine 'Grundig' GSS.box DSI 400 mit der (m.W.) letzten Firmware V1.25.0.157. Der Server mit dem DMS ist ein richtiger Server 2012R2, dort läuft i.d.R. kein DVBViewer, hier nur zum Test. Dessen Client ist natürlich der DMS, mit der Box direkt klappt es immer.

Im Wireshark habe ich einen Capturefilter 'host 192.168.17.14' gesetzt, damit passiert bei laufendem DMS erst mal gar nichts.

 

Dann habe ich (testweise) den lokalen DVBViewer gestartet, damit beginnt jeweils das Log. Im ersten, fehlerhaften Fall beendet der DMS die Verbindung und der Viewer meldet 'kein Gerät', während er nach Neustart beim selben Ablauf an eben dieser Stelle mit 'SETUP rtsp://' den Stream initialisiert.

 

Wie angedeutet passiert das eigentlich schon seit Jahren immer mal wieder nach Server-Reboots, lässt sich aber stets durch einen weiteren Neustart beheben. Bis zu dieser Analyse mit Wireshark hatte ich immer den Eindruck, es gäbe dann überhaupt keine Kommunikation mit der Box, habe deshalb nach Firewall, Netzwerk-Treiber und Switch geschaut, sogar mal eine separate Ethernetkarte für den (Hyper-V)-Server eingebaut, das alles hat nichts geändert - was jetzt auch klar ist. Kommunikation findet ja statt, aber der DMS agiert offenbar manchmal 'anders'...

 

Er wird als Dienst 'verzögert' gestartet, was er aber beim Start mit der Box kommuniziert, habe ich noch nicht geloggt. Womöglich wäre da der Grund für das spätere Verhalten des DMS erkennbar.

Edited by carmen.vvl
Link to comment
21 hours ago, carmen.vvl said:

dort läuft i.d.R. kein DVBViewer, hier nur zum Test. Dessen Client ist natürlich der DMS, mit der Box direkt klappt es immer.

 

Wohl eher umgekeht. Der Client des DMS ist der DVBViewer, andersherum geht es nicht.

 

21 hours ago, carmen.vvl said:

Dann habe ich (testweise) den lokalen DVBViewer gestartet, damit beginnt jeweils das Log. Im ersten, fehlerhaften Fall beendet der DMS die Verbindung und der Viewer meldet 'kein Gerät',

 

Das svcdebug.log des DMS ist eventuell aussagekräftiger als ein Wireshark-Log. Eine support.zip erspart viele Rückfragen.

 

21 hours ago, carmen.vvl said:

Er wird als Dienst 'verzögert' gestartet, was er aber beim Start mit der Box kommuniziert, habe ich noch nicht geloggt.

 

Der kommuniziert beim Start nicht mit der Box. Warum sollte er? Die Kommunikation beginnt erst, wenn ein Client (z.B. der DVBViewer) einen TV/Radio-Stream haben will und der DMS diesen wiederum von der Grundig-Box beziehen muss. Vorher interessiert die nicht.

 

Link to comment

Ja, gerne, der Viewer ist der Client.

Eine support.zip im Fehlerfall, nehme ich an? Der ist aber nicht beliebig reproduzierbar - bei nächsten Mal denke ich dran.

 

Wenn der DMS beim Start nicht 'seine' Hardware abfragt, sondern erst, wenn ein Client was anfordert, wie könnte denn dann das unterschiedliche Verhalten des DMS ab Zeile 9 der bis dahin identischen Kommunikation zu erklären sein? Am Client liegt es definitiv nicht, denn wenn der Server/DMS in diesem Zustand ist, funktioniert kein Client im Netz und auch kein Streaming im Browser.

 

Eigentlich bräuchte es ja eine Art support.zip vom DMS, oder ist dessen Zustand enthalten?

Link to comment
12 hours ago, carmen.vvl said:

wie könnte denn dann das unterschiedliche Verhalten des DMS ab Zeile 9 der bis dahin identischen Kommunikation zu erklären sein?

 

Das ist womöglich aus dem svcdebug.log ersichtlich. Es reicht einige Zeit zurück (ist davon abhängig, wie viel du inzwischen gemacht hast). Wenn du angibst, wann genau du das Wireshark-Log erstellt hast, kann man das eventuell im svcdebug.log wiederfinden. Du kannst auch erst mal selbst reinschauen.

 

Link to comment

Vielen Dank für die Antworten! Hier die support.zip, die svcdebug.log reicht weit genug zurück, passt aber in diese Antwort nicht mehr hinein.

Die Wireshark-logs habe ich am 12.06. um 11:18 (mit Fehler) und 11:23 (alles o.k.) erzeugt gespeichert, wenn es hilft habe ich die .pcapng-Dateien auch noch.

Das erste Log startet um 11:16:20, das zweite um 11:22:22.

support.zip

Edited by carmen.vvl
Link to comment

Aus der svcdebug.log habe ich jetzt nur den 12.06. heraus geschnitten, so passt es.

 

Zu den oben angegebenen Zeiten steht im svcdebug.log aber gar nichts. Auch die jeweilige Sequenz beim Start des DMS um 11:01:59 bzw. 11:21:41 sieht für mich identisch aus.

svcdebug_0612.zip

Edited by carmen.vvl
Ergänzung
Link to comment
9 hours ago, carmen.vvl said:

Die Wireshark-logs habe ich am 12.06. um 11:18 (mit Fehler) und 11:23 (alles o.k.) erzeugt gespeichert,

 

Das passt überhaupt nicht. Zu den Zeiten gab es laut Log im Media Server keine Zugriffe über ein virtuelles RTSP Gerät. Die wären sonst mit Sicherheit verzeichnet! Der letzte Zugriff davor war um 03:15, der erste danach um 15:15, beide vom EPG Updater.

 

Denkbar ist, dass es Zugriffe des DVBViewers waren. Laut der hardware.xml aus deiner support.zip benutzt der DVBViewer vorrangig die Grundig Sat>IP Box direkt, nicht über den DMS. Du hast dort an oberster Stelle zwei mit der Box assoziierte RTSP-Geräte (deshalb haben sie Priorität), danach zwei mit dem DMS assoziierte RTSP-Geräte. Umsortieren kannst du die Reihenfolge durch Ziehen mit der Maus.

 

Wenn du die RTSP-Zugriffe des DVBViewers loggen willst, muss er im Debug-Modus laufen (siehe DVBViewer-Einträge im Windows Startmenü). Das Ergebnis steht dann im DVBViewer.log.

 

Normalerweise sollte es so sein, dass nur der DMS direkt auf die Grundig Box zugreift und der DVBViewer nur über den DMS, so dass die Verwaltung der Hardware-Ressourcen allein dem DMS obliegt. Ansonsten droht Kuddelmuddel.

 

Link to comment

Ja, das mit der Reihenfolge der Geräte stimmt, vermutlich hatte ich das mal testweise so geändert. Den DVBViewer auf dem (virtualisierten) Server kann man eh nicht wirklich verwenden. Auf dem HTPC ist es natürlich so, dass alles über den DMS läuft, was eben nahezu unbegrenzte Möglichkeiten beim Aufnehmen und gleichzeitigen Live-TV bietet - das ist ja auch ein super tolles System!

 

Dann zeigt das Wireshark-Log also die Zugriffe des DVBViewers auf die Box. Das bedeutet aber, wenn der DMS nicht mit der SAT>IP-Box funktioniert, tut es der Viewer auch nicht - unabhängig vom DMS. Das hat mich ja gerade lange in Richtung Hardware bzw. Netzwerk-Basics schauen lassen, aber es findet ja Kommunikation statt. Und es zeigt, dass ein Neustart des DMS allein nichts bringt.

 

Dann werde ich die Priorität im Viewer mal so lassen und beim nächsten Auftreten den Debug-Modus aktivieren, wenn das die meisten Informationen liefert?

Was könnte es denn noch Gemeinsames von DVBViewer und DMS zwischen der Software und dem Netzwerk geben, was dieses Verhalten bewirken bzw. erklären könnte?

Link to comment
5 hours ago, carmen.vvl said:

Was könnte es denn noch Gemeinsames von DVBViewer und DMS zwischen der Software und dem Netzwerk geben, was dieses Verhalten bewirken bzw. erklären könnte?

 

On 6/12/2019 at 12:20 PM, carmen.vvl said:

der lokale DVBViewer sagt, das kein Gerät verfügbar ist.

 

Wenn der sowas sagt, hat der DVBViewer kein Gerät gefunden, das für den Empfang brauchbar ist. Da es bei ihm aber 4 RTSP-Geräte gibt, muss bei sämtlichen die Initialisierung gescheitert sein, egal ob sie der Grundig Box oder dem DMS zugeordnet sind.

 

Im svcdebug.log gibt es entsprechende Einträge vom letzten Montag. Da ist dem DMS als RTSP Client gleiches passiert, bei allen seinen vier RTSP-Geräten:

 

Quote

10.06.19 19:05:49.752 TRTSPNetworkStream   DoOpen           no ports
10.06.19 19:05:49.768 TRTSPUDPClient       AllocateHardware Open failed
10.06.19 19:05:49.770 TRTSPNetworkStream   DoOpen           no ports
10.06.19 19:05:49.786 TRTSPUDPClient       AllocateHardware Open failed
10.06.19 19:05:49.786 TRTSPNetworkStream   DoOpen           no ports
10.06.19 19:05:49.802 TRTSPUDPClient       AllocateHardware Open failed
10.06.19 19:05:49.802 TRTSPNetworkStream   DoOpen           no ports
10.06.19 19:05:49.817 TRTSPUDPClient       AllocateHardware Open failed

 

Bei RTSP muss der Client dem Server einen freien Port angeben, an den dieser den (UDP-)TV-Stream schicken soll. Den Port suchen DMS und DVBViewer im Bereich 52000 - 52100 - siehe dazu auch den Einstellungen-Dialog der RTSP-Geräte.

 

Wenn sich kein freier Port findet bzw. jeder der Versuche mit einer Fehlermeldung von Windows endet, liegt in dem PC netzwerktechnisch etwas grundsätzlich im Argen. Das kann zum Beispiel passieren, wenn Clients aufgrund irgendwelcher Regeln überhaupt keine UDP-Streams empfangen dürfen. Clients auf anderen PCs / Geräten sind davon natürlich nicht betroffen. Bei denen funktioniert es.

 

Die OPTIONS-Einträge in dem ersten Wireshark-Log entstehen dadurch, dass der DVBViewer/DMS als erstes (noch vor der Portsuche) Kontakt zur Grundig Box aufnimmt, um festzustellen, ob sie überhaupt erreichbar ist. Das klappt, da als Antwort ein Statuscode 200 OK zurückkommt - hierbei handelt es sich um eine TCP-Verbindung, nicht um UDP! 

 

Die erfolgreiche Kontaktaufnahme nützt jedoch nichts, wenn es keinen Port gibt, um den TV Stream zu empfangen. Deshalb probiert der DVBViewer/DMS das nächste RTSP Gerät - daraus resultiert der nächste OPTIONS-Eintrag im Wireshark-Log - bis keines mehr da ist. Was dabei in deinem PC schiefläuft, lässt sich anhand der vorhandenen Infos schlecht feststellen. In den Logs sieht man nur die Auswirkungen.  Hier ein Link zu einem Fall (und dort ein weiterer Link), bei dem sowas schon mal aufgetreten ist.

 

Link to comment

Vielen Dank für Erklärung! Dann könnte ja am ehesten netstat das Werkzeug sein, um zu schauen, was da los ist. Wie schon gesagt tritt das nur sporadisch nach einem Neustart mal auf - den gibt es meistens nur einmal im Monat nach den Updates - aber eigentlich schon seit Jahren über alle sonstigen Veränderungen an Soft- und Hardware hinweg, denn vor ein paar Monaten gab es ein neues Mainboard, das Windows ist aber noch das alte...

Link to comment

Problem gelöst!


Es was der DNS-Service, der auf diesem Server läuft, der nimmt sich im Namen der Sicherheit einige Tausend UDP-Ports, anscheinend mal hier, mal da. Das Verhalten und die Lösung ist z.B. hier beschrieben: https://serverfault.com/questions/558104/dns-exe-allocates-5000-ports-immediately
Ich halte jetzt einfach mit SocketPoolExcludedPortRanges 52000-52100 den Bereich für die RTSP-Geräte frei, das sollte dauerhaft funktionieren!

 

Nochmal vielen Dank für die Unterstützung und den entscheidenden Hinweis!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...