tb99de Posted January 5 Share Posted January 5 Hallo zusammen, ich habe neuerdings das Problem, dass der DVBViewer nach Start die o.a. Meldung anzeigt und somit auch kein Bild ausgibt. Die Systeme sind seit Monaten unverändert, das Problem existiert sowohl beim Start des DVBViewers auf dem Server als auch auf dem Client-PC, als auch beim start von Kodi von einem Fire-TV. Server: DMS 3.2.4.2 DVBViewer auf Server 7.2.4.2 DVBViewer auf Client 7.2.4.2 Also ich Starte den DVBViewer, das letzte Programm soll eingestellt werden (alle Tests mit ZDF HD), in ca. 50% der Fälle erhalte ich die Fehlermeldung. Habe hier bereits einiges gelesen und auf den PC's testweise die Firewall und die Virenscanner deaktiviert, das Problem bleibt. Wenn der Stream einmal läuft, funktioniert er immer, auch beim Umschalten. Es tritt nur beim Start auf. Beim betrachten des Tuners im DD Control Center sehe ich auch im Fehlerfall für einige Sekunden die Streamdaten (Qualität, Frequenz, ...). Ein Auszug aus den Log-Dateien, wo man Unterschiede zwischen ok und Fehler sieht: dvbviewer_start fehler.log 05.01.24 09:42:06.537 TfrmMain SetTuner Start 05.01.24 09:42:06.572 TfrmMain AllocateHardware DVBViewer Media Server (SERVER1) 1 05.01.24 09:42:06.572 TfrmMain SetTuner Found usable hardware 05.01.24 09:42:06.572 TRTSPNetworkStream SetTuner TType: 1, Freq: 11362, Symrate: 22000, LOF: 9750, Tone: 0, Pol: 0, DiseqC: 0, FEC: 2, APID: 6122, VPID: 6110, PMT: 6100, SID: 11110, TID: 1011, NID: 1, SatMod: 134, DiseqCVal: 0, Flags: 24, Group: 0 05.01.24 09:42:21.573 TRTSPNetworkStream SETUP 10060 05.01.24 09:42:21.573 TfrmMain SetTuner failed 3 05.01.24 09:42:21.573 TfrmMain SetTuner End svcdebug_start fehler.log 05.01.24 09:42:22.378 TRTSPUDPClient SetTuner Tuner set 05.01.24 09:42:22.378 SETUP 200 src=1&freq=11362&msys=dvbs2&plts=on&fec=23&pol=h&ro=0.35&sr=22000&mtype=8psk&pids=0&tnr=1,11362,22000,9750,0,0,0,2,6122,6110,6100,11110,134,0,24,0,1011,1,-1,192,6110&prio=10 05.01.24 09:42:42.548 TRTSPUDPClient Release Digital Devices DVB-S2 Tuner 2 (2) 05.01.24 09:42:42.548 TRTSPUDPClient Free Digital Devices DVB-S2 Tuner 2 (2) dvbviewer_start ok.log 05.01.24 09:38:55.133 TfrmMain SetTuner Start 05.01.24 09:38:55.178 TfrmMain AllocateHardware DVBViewer Media Server (SERVER1) 1 05.01.24 09:38:55.178 TfrmMain SetTuner Found usable hardware 05.01.24 09:38:55.178 TRTSPNetworkStream SetTuner TType: 1, Freq: 11362, Symrate: 22000, LOF: 9750, Tone: 0, Pol: 0, DiseqC: 0, FEC: 2, APID: 6122, VPID: 6110, PMT: 6100, SID: 11110, TID: 1011, NID: 1, SatMod: 134, DiseqCVal: 0, Flags: 24, Group: 0 05.01.24 09:39:06.321 TfrmMain SetTuner End svcdebug_start ok.log 05.01.24 09:39:06.339 TRTSPUDPClient SetTuner Tuner set 05.01.24 09:39:06.339 SETUP 200 src=1&freq=11362&msys=dvbs2&plts=on&fec=23&pol=h&ro=0.35&sr=22000&mtype=8psk&pids=0&tnr=1,11362,22000,9750,0,0,0,2,6122,6110,6100,11110,134,0,24,0,1011,1,-1,192,6110&prio=10 05.01.24 09:39:06.340 PLAY 200 addpids=18&delpids=0 05.01.24 09:39:06.373 PLAY 200 addpids=6110,6122,0,6100,6130,17 Für Tipps zur Beseitigung des Problems wäre ich sehr dankbar. Quote Link to comment
Griga Posted January 5 Share Posted January 5 vor 4 Minuten schrieb tb99de: 05.01.24 09:42:21.573 TRTSPNetworkStream SETUP 10060 Der Fehlercode kommt von Windows, siehe hier: Zitat WSAETIMEDOUT 10060 Zeitüberschreitung bei der Verbindung. Ein Verbindungsversuch ist fehlgeschlagen, weil die verbundene Partei nach einer bestimmten Zeit nicht ordnungsgemäß reagiert hat oder die hergestellte Verbindung fehlgeschlagen ist, weil der verbundene Host nicht reagiert hat. Ist bei dir Bitdefender als Sicherheitssoftware aktiv? Solche Fragen müsste ich nicht stellen, wenn es eine support.zip gäbe. Quote Link to comment
tb99de Posted January 5 Author Share Posted January 5 Sorry wegen der Support.zip, sind im Anhang. Nein, kein Bitdefender (den Thread habe ich gelesen). support_client.zip support_server.zip Quote Link to comment
Griga Posted January 5 Share Posted January 5 Was bei deinen Log-Auszügen auffällt: Die SETUP-Request des DVBViewers (die aus dem Tunen um 09:42:06 resultiert), ist im Server erst um 09:42:22 verarbeitet, also ca. 16 Sekunden später (vorausgetzt, die Server- und Client-Systemzeiten sind ausreichend synchron). Die Bestätigung an den Client nützt nichts mehr, da er schon um 09:42:21 mit einem Timeout-Fehler abbricht. Wer oder was trödelt da so lange? Im Erfolgsfall beträgt die Differenz nur 11 Sekunden. Das wollte ich in deinem svcdebug.log untersuchen, aber deine support_server.zip enthält keines??? Du kannst mal probeweise in den Einstellungen der RTSP Network Devices des Clients das Verbindungs-Timeout deutlich hochsetzen (danach auch im Optionen-Fenster "Übernehmen", damit es wirksam wird). Quote Link to comment
tb99de Posted January 5 Author Share Posted January 5 Die Zeiten sind synchron, Abweichung < 200ms Anbei die Logfiles, die hatte ich zur Auswertung vorher woanders hin verschoben 😌 Diese 11s und 16s sind mir auch aufgefallen, irgendetwas steht da auf der Bremse. Aber was/wer? logfiles.zip Quote Link to comment
tb99de Posted January 5 Author Share Posted January 5 (edited) Anbei die Logfiles wenn ich den DVBViewer lokal auf dem Server starte, falls interessant. Beim ersten Start war schnell ein Bild da, beim zweiten start kam kein Bild. log_local.zip Verbindungs-Timeout von 4000ms (Standard) auf 20000ms gesetzt, keine Änderung Wenn ich irgendetwas testen oder ausprobieren soll gerne, bin für jeden Tipp dankbar. Edited January 5 by tb99de Quote Link to comment
Griga Posted January 6 Share Posted January 6 vor 19 Stunden schrieb tb99de: Anbei die Logfiles, die hatte ich zur Auswertung vorher woanders hin verschoben Wenn man die Abläufe mit Fehler gegenüberstellt: DVBViewer: 05.01.24 09:42:06.537 TfrmMain SetTuner Start 05.01.24 09:42:06.572 TfrmMain AllocateHardware DVBViewer Media Server (SERVER1) 1 05.01.24 09:42:06.572 TfrmMain SetTuner Found usable hardware 05.01.24 09:42:06.572 TRTSPNetworkStream SetTuner TType: 1, Freq: 11362, Symrate: 22000, LOF: 9750, Tone: 0, Pol: 0, DiseqC: 0, FEC: 2, APID: 6122, VPID: 6110, PMT: 6100, SID: 11110, TID: 1011, NID: 1, SatMod: 134, DiseqCVal: 0, Flags: 24, Group: 0 05.01.24 09:42:21.573 TRTSPNetworkStream SETUP 10060 05.01.24 09:42:21.573 TfrmMain SetTuner failed 3 05.01.24 09:42:21.573 TfrmMain SetTuner End Server: 05.01.24 09:42:06.596 TRTSPWebserver ClientConnect 054FD330 05.01.24 09:42:22.206 SetStandbyBlock RTSP-Client 192.168.50.101 (...) 05.01.24 09:42:22.206 TRTSPUDPClient SetTuner TType: 1, Freq: 11362, Symrate: 22000, LOF: 9750, Tone: 0, Pol: 0, DiseqC: 0, FEC: 2, APID: 6122, VPID: 6110, PMT: 6100, SID: 11110, TID: 1011, NID: 1, SatMod: 134, DiseqCVal: 0, Flags: 24, Group: 0 (...) 05.01.24 09:42:22.377 TRTSPUDPClient AllocateHardware Digital Devices DVB-S2 Tuner 2 (2) (...) 05.01.24 09:42:22.377 TBDADigitalDevices SetTuner TType: 1, Freq: 11362, Symrate: 22000, LOF: 9750, Tone: 0, Pol: 0, DiseqC: 0, FEC: 2, APID: 6122, VPID: 6110, PMT: 6100, SID: 11110, TID: 1011, NID: 1, SatMod: 134, DiseqCVal: 0, Flags: 24, Group: 0 05.01.24 09:42:22.378 TRTSPUDPClient SetTuner Tuner set 05.01.24 09:42:22.378 SETUP 200... dann fällt auf, dass der Verbindungsversuch ClientConnect schon nach wenigen ms registriert wird, aber dann gibt es erst mal an die 16 Sekunden Pause, bis weiteres passiert. Wodurch die Pause entsteht, verraten die Logs leider nicht. Das verliert sich im Dunkeln der vom DVBViewer & DMS verwendeten Netzwerkbibliotheken und der Windows Socket-Implementation. Probiere ich das gleiche hier mit einem Zugriff von einem Remote-Client (via LAN -> Router -> WLAN), geht es absolut zügig über die Bühne: 06.01.24 08:17:02.411 TRTSPWebserver ClientConnect 0439BB60 06.01.24 08:17:02.427 SetStandbyBlock RTSP-Client 192.168.178.36 (...) 06.01.24 08:17:02.427 TRTSPUDPClient SetTuner TType: 1, Freq: 11494, Symrate: 22000, LOF: 9750, Tone: 0, Pol: 0, DiseqC: 3, FEC: 2, APID: 5102, VPID: 5101, PMT: 5100, SID: 10301, TID: 1019, NID: 1, SatMod: 134, DiseqCVal: 0, Flags: 24, Group: 0 (...) Selbst im Erfolgsfall sind die Zeiten bei dir viel länger. Die einzige Stelle im DMS-Code, wo es theoretisch länger dauern könnte, ist die Suche nach zwei freien nebeneinanderliegenden Ports, über die die UDP-Streams an den Client rausgeschickt werden. Der Portbereich lässt sich in den DMS-Optionen -> RTSP Server konfigurieren. Ob eine Änderung etwas bringt, kannst du nur durch Probieren herausfinden. Eine andere Möglichkeit wäre, im Client RTSP-Gerät das Streaming-Protokoll von UDP auf TCP umzustellen und zu schauen, was das macht. vor 19 Stunden schrieb tb99de: Anbei die Logfiles wenn ich den DVBViewer lokal auf dem Server starte, falls interessant. Da ist kein WSAETIMEDOUT-Fehler zu sehen. Laut den Logs ist alles fehlerfrei und zügig abgelaufen. Es kommt auch nicht zu der oben beschriebenen Verzögerung nach ClientConnect. vor 22 Stunden schrieb tb99de: Die Systeme sind seit Monaten unverändert Das sagen alle Anwender, und später stellt sich dann beiläufig heraus, dass das Mainboard getauscht und Windows neu installiert wurde Manchmal wurde auch irgendwas "Harmloses" mit unerwarteten Auswirkungen installiert. Oder Windows Update hat es gefallen, hinterrücks einen neuen Treiber ins System zu schleusen... wenn das Auftreten des Problems noch nicht lange her ist, könntest du auch eine Systemwiederherstellung auf einen Zeitpunkt davor probieren, sofern möglich. Quote Link to comment
tb99de Posted January 6 Author Share Posted January 6 Erst einmal Danke Girga, für deine genaue Analyse und Mühe!! Sicher ist, das ich an der Config DMS Server/DVBV Client nichts geändert habe. Hardware auch unverändert. Einzig die Windows-Updates wurden installiert, was ja oft Probleme verursachen kann. Ich vermute, dass es am Server liegt. Da sowohl der DVBV Client als auch Kodi auf Fire TV diese Problem jetzt haben (und die laufen seit Jahren). Außerdem auch der Test-DVBV-Client (wird sonst nie benutzt) auf dem Server ja öfters kein Bild bekommt (auch wenn leider keine Fehlermeldung sichtbar ist). Als erstes werde ich deine Vorschläge testen und berichten. Quote Link to comment
tb99de Posted January 6 Author Share Posted January 6 Änderung des Portbereich in DMS-Optionen -> RTSP Server und Umstellung auf TCP ohne Erfolg. 😐 Testweise die Treiber der DD Karten im Server deinstalliert, Neustart, Installiert ohne Erfolg. Heute wurde es dann stressig... die bessere Hälfte war schon genervt, da ich auf dem HTPC im Wohnzimmer den DVBViewer mehrmals neu starten musste. Quote Link to comment
tb99de Posted January 8 Author Share Posted January 8 Es funktioniert momentan wieder tadellos 🙂 Ich habe nur (aus anderen Gründen) meinen Raspi inkl. Pi-Hole heruntergefahren, Pi-Hole ist in der Fritz Box als DNS Sever eingetragen. Entweder Zufall oder es hängt Pi-Hole zusammen (und Pi Hole ist schon seit Jahren bei mir aktiv). Kann es sein, dass der DMS oder DVBV beim Start des DVBV IP-Adressen anspricht, die per DNS aufgelöst werden müssen und evtl. geblockt wurden? Quote Link to comment
Griga Posted January 9 Share Posted January 9 vor 17 Stunden schrieb tb99de: Kann es sein, dass der DMS oder DVBV beim Start des DVBV IP-Adressen anspricht, die per DNS aufgelöst werden müssen und evtl. geblockt wurden? Keine Ahnung, was die Netzwerkbibliotheken und Windows im Hintergrund veranstalten. Eigentlich werden DNS Server ja nur für die Umwandlung von Hostnamen in IP-Adressen benötigt. Sat>IP mit dem DVBViewer als Client und dem DMS als Server verwendet jedoch normalerweise nur IP-Adressen, so dass eine DNS-Abfrage unnötig ist. Um herauszufinden, ob trotzdem "pro forma" eine DNS-Abfrage erfolgt, müsste ich den Ablauf mit dem Debugger verfolgen. Quote Link to comment
tb99de Posted January 9 Author Share Posted January 9 Ich werde beide Debugger aktivieren, mit und ohne Pi-Hole testen und versuchen das Problem zu reproduzieren. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.