Nach wechsel des USB-Ports kein DVB-C-Empfang mit dem Viewer über den Server

[Griga]

Am 2.9.2025 um 13:46 schrieb Bob.Dig:

Der Viewer hat aber wie gesagt die Direktverbindung sowohl für den Server als auch für die Hardware eingestellt.

 

Den Satz verstehe ich nicht.

 

Am 2.9.2025 um 13:46 schrieb Bob.Dig:

Und dass der DMS andere Netze auch nutzen "möchte" ist doch sicherlich kein Problem.

 

Konkrete Probleme gab es z.B. beim Empfang von MagentaTV (UDP/RTP Multicast aus dem Internet), als Windows versucht hat, den Empfang über einen virtuellen (VPN-)Netzwerkadapter zu routen, solange im DVBViewer/DMS die Adresse des zu nutzenden Adapters auf "Automatic" stand. Siehe dazu auch hier. Ich weiß allerdings nicht, ob und wie es zu Auswirkungen auf TCP oder das darauf aufbauende HTTP kommen könnte. Überraschungen erlebt man bei Netzwerkkram jedoch immer wieder...

 

Bei dir überlagern sich offenbar zwei Effekte: Erstens dauert die Initialisierung und das Tunen bei deinem DVB-Gerät ungewöhnlich lange, und zweitens gibt es eine rätselhafte 4 - 5 Sekunden lange Verzögerung zwischen dem Herstellen der TCP Verbindung vom DVBViewer Client zum Media Server und der Ankunft der darüber gesendeten Tune Request (RTSP SETUP Kommando). Beides zusammen übersteigt dann leicht das Tuning Timeout. Der zweite Effekt ist wahrscheinlich netzwerktechnisch bedingt und muss irgendwie mit deiner Konfiguration zusammenhängen, da es normalerweise nicht auftritt - bei mir beträgt die Zeitspanne wie gesagt 8 ms.

 

Am 31.8.2025 um 11:35 schrieb Griga:

Wenn ich das Problem hätte, würde ich noch dies und das experimentell probieren, z.B. ob die 4 bis 5 Sekunden Verzögerung auch auftreten, wenn der Sender im DMS bereits wegen einer Aufnahme getuned ist. Normalerweise müsste das Bild im Client nach der Senderwahl sofort da sein.

 

Das war mein Vorschlag zur Verifikation. Dazu müsste im DMS am besten ein Radiosender (!) aufgenommen werden und der DVBViewer-Client zwar schon gestartet sein, sich aber im Zustand "Wiedergabe aus" befinden (Radiosender, weil bei Video vermehrt wiedergabebedingte Verzögerungen wie Pufferung, Warten auf einen Einstiegspunkt und Herstellen des Audio/Video-Syncs hinzukommen). Wenn du im DVBViewer nun den selben Sender einschaltest, entfällt die Initialisierung und das Tunen im Server. Deshalb dürfte der Wiedergabestart nicht wesentlich länger als eine Sekunde dauern. Beginnt die Wiedergabe erst nach 4 bis 5 Sekunden, ist dies wahrscheinlich auf ein Netzwerkproblem zurückzuführen.

 

[Bob.Dig]

vor 22 Stunden schrieb Griga:

 

Dazu müsste im DMS am besten ein Radiosender (!) aufgenommen werden und der DVBViewer-Client zwar schon gestartet sein, sich aber im Zustand "Wiedergabe aus" befinden (Radiosender, weil bei Video vermehrt wiedergabebedingte Verzögerungen wie Pufferung, Warten auf einen Einstiegspunkt und Herstellen des Audio/Video-Syncs hinzukommen). Wenn du im DVBViewer nun den selben Sender einschaltest, entfällt die Initialisierung und das Tunen im Server. Deshalb dürfte der Wiedergabestart nicht wesentlich länger als eine Sekunde dauern. Beginnt die Wiedergabe erst nach 4 bis 5 Sekunden, ist dies wahrscheinlich auf ein Netzwerkproblem zurückzuführen.

 

Hab ich nun mal nachgestellt, wobei ich den Viewer erst noch gestartet habe, aber das ist bei mir immer ohne Wiedergabe, sollte also passen. Und es dauert schon einige Sekunden.

 

20250904_1.zip

Edited September 4 by Bob.Dig

[Bob.Dig]

Habe jetzt außerdem auf die Direkt-Verbindung verzichtet und nutze nun die vom DMS "vorgeschlagene" Verbindung. Werde dazu Logs nachreichen, weil ich es gerade nicht testen kann. 

[Bob.Dig]

vor einer Stunde schrieb Bob.Dig:

Werde dazu Logs nachreichen

Kam mir gefühlt nicht schneller vor. 

20250905_1.zip

[Griga]

Am 4.9.2025 um 13:35 schrieb Bob.Dig:

Hab ich nun mal nachgestellt, wobei ich den Viewer erst noch gestartet habe, aber das ist bei mir immer ohne Wiedergabe, sollte also passen. Und es dauert schon einige Sekunden.

 

Wegen hier:

 

04.09.25 13:30:51.586 TRTSPWebserver       ClientConnect    0519A240
04.09.25 13:30:56.225 TServiceMain         AddReference     TRTSPInterleavedClient 192.168.10.10: 3

 

ClientConnect beruht darauf, dass das RTSP Network Device im DVBViewer bei seiner Initialisierung kurz mit einem OPTIONS-Kommando testet, ob der Server überhaupt da ist. Er muss innerhalb von 3 Sekunden antworten, sonst gilt er als verschollen. Das klappt offenbar bei dir.

 

Trotzdem sollte es bis AddReference (das auf dem SETUP-Kommando mit Tunerdaten beruht) wesentlich schneller gehen, insbesondere wenn der DMS den Sender bereits empfängt. Ich möchte noch mal im Code überprüfen, was dazwischen im DVBViewer und DMS alles passieren kann. Vielleicht komme ich morgen dazu. Heute Nachmittag war dafür etwas zu viel Betrieb im Forum...

 

[Bob.Dig]

vor 18 Minuten schrieb Griga:

Wegen hier

Und was sagst Du zu meinem letzten Upload.

[Griga]

Noch keine Zeit für gefunden.

[Griga]

Am 4.9.2025 um 13:35 schrieb Bob.Dig:

Hab ich nun mal nachgestellt, wobei ich den Viewer erst noch gestartet habe,

 

Ich habe zu diesem Vorgang die wesentlichen Punkte aus dem DVBViewer.log und svcdebug.log zusammengestellt und in die richtige Reihenfolge gebracht, dazu Vorgänge ergänzt, die nicht im Log auftauchen, aber zwangsläufig stattgefunden haben müssen. Zu den Zeiten im svcdebug.log musste ich 900 ms addieren (geschätzt), weil die Uhren im Server und Client wieder nicht ganz synchron sind.
 

Spoiler

 

//DVBViewer
04.09.25 13:30:52.446 TfrmMain             SetTuner         Start
//sends OPTIONS request to server

//DMS, 900 ms added to all DMS log times
04.09.25 13:30:52.468 TRTSPWebserver       ClientConnect    0519A240 (client connects)
//replies 200 OK to OPTIONS

//DVBViewer
04.09.25 13:30:52.468 TfrmMain             AllocateHardware DVBViewer Media Server (V1000) 2
04.09.25 13:30:52.468 TfrmMain             SetTuner         Found usable hardware //RTSP Network device initiaization succeeded
//tuning of RTSP network device by sending SETUP request to server

//4600 ms gap - what happened here?

//DMS
04.09.25 13:30:57.125 TServiceMain         AddReference     TRTSPInterleavedClient 192.168.10.10: 3 //SETUP Request arrived
04.09.25 13:30:57.125 TRTSPInterleavedClient SetTuner 
04.09.25 13:30:57.125 TRTSPInterleavedClient AllocateHardware Hauppauge WinTV-dualHD DVBC Tuner 2 (1) //fast, already initialized
04.09.25 13:30:57.125 TRTSPInterleavedClient SetTuner         Tuner set //fast, already tuned
04.09.25 13:30:57.125 SETUP                200    //reply 200 OK to client SETUP request
04.09.25 13:30:57.202 PLAY                 200              addpids=18&delpids=0  //reply 200 OK to client PLAY request (EPG data)
04.09.25 13:30:57.216 PLAY                 200              addpids=111,0,110,17  //reply 200 OK to client PLAY request (PMT, PAT, audio, SDT)

(DVBViewer)
04.09.25 13:30:57.283 TfrmMain             SetTuner         End //tuning finished

 

 

Die Untersuchung wird allmählich forensisch.  Es fällt auf, dass die Kommunikation zwischen Client und Server grundsätzlich so zügig wie erwartet abläuft, nur an einer Stelle nicht, nämlich wenn der DVBViewer die Tune- bzw. SETUP Request formuliert und sendet, wobei offen bleibt, ob die Verzögerung im DVBViewer Code, im Netzwerk oder im DMS Code stattfindet. Möglich wäre alles. Das macht die Sache schwierig. Es fragt sich vor allem, warum eine Request bei bereits bestehender TCP Verbindung so lange braucht, aber alle anderen nicht. 

 

[Griga]

Am 5.9.2025 um 18:35 schrieb Bob.Dig:

Und was sagst Du zu meinem letzten Upload.

 

UDP und andere Adapter-IP, aber zeitlich das gleiche Verhalten, soweit ich sehen kann - etwas schwierig zu beurteilen, weil die Systemzeit beim Server- und Client-PC noch mehr abweicht.

 

Ich habe das gestern nachvollzogen und bin dabei mit dem Debugger in Einzelschritten durch die relevanten Code-Abschnitte im DVBViewer gesteppt, in der Hoffnung, auf etwas zu stoßen, bei dem es zumindest theoretisch zu einer so langen Verzögerung kommen könnte. Habe aber bislang nichts gefunden. Demnächst versuche ich das noch mal beim Server.

 

Ich komme zur Zeit nur sporadisch dazu, das weiter zu verfolgen. Es gibt genug anderes zu tun. Jedenfalls sehr rätselhaft 

 

[Bob.Dig]

Da das Problem wieder aufgetaucht ist, hab ich mal nach einem neuen Treiber geguckt und im WinTV-Paket war tatsächlich einer. Bis jetzt sieht es gut aus und ich bleib einfach mal optimistisch. 

Edited November 28 by Bob.Dig