Search the Community

Hallo, ich möchte gerne einen Client mit dem Mediaserver per SAT>IP (RTSP) verbinden. Bei dem Client handelt es sich um einen VU+ SOLO SE receiver mit OpenATV 7.3 image. Dieses enthält ein (extra herunterladbares) SAT>IP Client plugin. Es findet den DVBViewer Media Server ohne Problem, aber das Streamen des Signals funktioniert nicht. (weder Sender, noch im "Signalfinder", welcher die Signalstärke eines Transponders anzeigt) Nach Fehlersuche und Reproduktion komme ich zu dem Schluss, dass es sich hier höchstwahrscheinlich um ein Problem mit der Mediaserver Software handelt. Ein Wireshark trace, welcher lokal auf dem gleichen Rechner wie der Mediaserver läuft (wireshark_trace.zip -> wireshark_net_dump.pcapng) zeigt, dass der verwendete Client nach dem Verbindungsaufbau direkt SETUP sendet (was nach meinem Verständnis der Spezifikation des SAT>IP Protokolls erlaubt ist). Jedoch kommt die Antwort 200 OK erst nachdem der Client bereits das Schließen der Netzwerkverbindung angefordert hat (wahrscheinlich nach Timeout nach 4 Sekunden). Die falsche Reihenfolge der Pakete (noch Daten nach Ende der Verbingung) führt zu connection reset durch client. Dieser Trace wurde entsprechend Anleitung während der Erstellung der support.zip reproduziert. svcdebug.log zeigt, dass das eigentliche tunen nur 2 sekunden dauert und die Antwort eigentlich dann schon bereitseht. Trotzdem wird die Antwort erst weitere 2 Sekunden später tatsächlich als Paket rausgeschickt und der Client schließt die Verbindung. 06.02.24 21:03:24.274 TRTSPWebserver ClientConnect 04440740 06.02.24 21:03:24.322 SetStandbyBlock RTSP-Client 192.168.178.22 06.02.24 21:03:24.322 TServiceMain AddReference RTSP-Client 192.168.178.22: 1 06.02.24 21:03:24.322 TRTSPUDPClient SendBufSizeUDP 13280000 06.02.24 21:03:24.322 TRTSPUDPClient SetTuner TType: 0, Freq: 314000, Symrate: 6900, LOF: 0, Tone: 0, Pol: 5, DiseqC: 0, FEC: 0, APID: 0, VPID: 0, PMT: 0, SID: 0, TID: 0, NID: 0, SatMod: 0, DiseqCVal: 0, Flags: 0, Group: 0 06.02.24 21:03:24.388 TBDATwinhan OpenDevice bvTwinhan 06.02.24 21:03:24.388 TRTSPUDPClient AllocateHardware TechniSat Mantis DVBC BDA Receiver 06.02.24 21:03:24.388 TRTSPUDPClient SetTuner Got new hardware 06.02.24 21:03:24.388 TBDATwinhan SetTuner TType: 0, Freq: 314000, Symrate: 6900, LOF: 0, Tone: 0, Pol: 5, DiseqC: 0, FEC: 0, APID: 0, VPID: 0, PMT: 0, SID: 0, TID: 0, NID: 0, SatMod: 0, DiseqCVal: 0, Flags: 0, Group: 0 06.02.24 21:03:26.324 TRTSPUDPClient SetTuner Tuner set 06.02.24 21:03:26.325 SETUP 200 freq=314&msys=dvbc&mtype=256qam&sr=6900&pids=none 06.02.24 21:03:28.270 TRTSPWebserver ClientDisconnect 04440740 Ich habe hier verschiedene Möglichkeiten bedacht, woran es liegen könnte, folgendes konnte ich ausschließen: - langsames Netzwerk -> Netzwerk is Ethernet-kabelverbindung an gleichem Switch (in Fritzbox integriert), PC mit media server mit 1 GB, die Box mit dem client mit 100 MB. Ping zeigt <1ms. Es war während des Tests kein größerer Traffic im Netzwerk - Problem mit Firewall -> deaktivieren von allen Software-Firewall (windows defender und Bitdefender, sonst normalerweise nur Bitdefender eingeschaltet) macht keinen Unterschied. - tuner selbst langsam -> mit DVBViewer als client funktioniert das Kanalumschalten schnell Ich habe dann noch etwas experimentiert und folgendes gefunden: Egal wie oft ich es (mit dem "Signalfinder") reproduziere, es ist immer exakt der gleiche Ablauf: nach Verbindungsaufbau kommt zuerst SETUP request. Dann schließt der Client 4 Sekunden später die Verbindung. Direkt im Anschluss an diese Anforderung wird die Antwort rausgeschickt (wireshark_trace.zip -> wireshark_net_dump2.pcapng) - hier beim ersten mal 200 OK, und dann 2mal 503 Service unavailable - wahrscheinlich, weil es zu oft nacheinander war und der Tuner noch als beschäftigt galt, da wegen geschlossener Verbindung kein Teardown erfolgt: Das scheint kein Zufall zu sein. Ich habe dann nachgeschaut, wass DVBViewer als Client anders macht (über Loopback verbunden wireshark_trace.zip -> wireshark_loopback_dump.pcapng) und sehe, dass dieser zunächst nach OPTIONS fragt und erst dann SETUP ausführt (was in dem Fall sogar nur nach 1s beantwortet wurde): Das ein ähnliches Verhalten zeigt auch VLC media player (wireshark_trace.zip -> wireshark_loopback_dump_vlc.pcapng) - dieser schiebt auch noch ein DESCRIBE dazwischen: Dieser Test zeigt auch, dass die URL in Ordnung ist (ich habe im VLC Media Player die gleiche URL eingegeben, wie vom "Signalfinder" der VU Solo SE box verwendet) Es scheint also wohl ein reproduzierbarer Bug zu sein - wenn nach Aufbau der TCP Verbindung zum RTSP Port als erstes Sofort SETUP gechickt wird, wartet der MediaServer aus irgendeinem Grund auf die nächte Aktivität vom Client, bevor die Antwort rausgeschickt werden kann. Die Aktivität ist hier dann leider das Schließen der Verbindung nach Timeout. Nur wenn es vorher irgendwelche andere Kommunikation auf der gleichen TCP-Verbindung gab, funktioniert alles. Edit: Achso, die Angaben hatte ich noch vergessen: TVKarte: TechniSat CableStart HD2 mit CI slot (kein Modul gesteckt), Treiber 1.1.1.502 Grafikkarte: Nvidia GeForce RTX 2080 Ti, Treiber 27.21.14.5206 (sollte aber wohl nicht relevant sein) support.zip wireshark_trace.zip

Hallo, ich bin mir nicht sicher, ob das Thema hier hin gehört oder besser in DVB Hardware aufgehoben wäre - falls ja, bitte dahin verschieben. Ich betreibe den DVBViewer Media Server mit vier lokalen DuoFlex S2 von Digital Devices und habe zusätzlich einen KATHREIN EXIP414/E Sat>IP Server per Gigabit-Netzwerk über Kupferkabel eingebunden: Da ich ein Netzlaufwerk als Aufnahmeordner eingerichtet habe, habe ich mal viele gleichzeitige Aufnahmen gestartet, um das Aufnahmeverhalten zu beobachten. Dabei ist mir aufgefallen, dass ein Tuner (Tuner 2) des KATHREIN KATHREIN EXIP414/E Sat>IP Server permanent Discontinuities erzeugt: Zunächst dachte ich an eine Überlastung des Netzwerks und habe die Aufnahme wieder in einen lokalen Ordner (SSD) umgeleitet, so dass das Netzwerk nur in eingehender Richtung genutzt werden muss. Aber auch hier zeigt sich der gleiche Fehler: Ich vermute nun, dass der KATHREIN EXIP414/E Sat>IP Server kaputt ist bzw. ein Tuner (Tuner 2) fehlerhaft arbeitet. Jedoch habe ich nun noch einmal einen weiteren Versuch gestartet und dabei festgestellt, dass der Fehler zu Tuner 1 "mitwandert": Eine weiterer Versuch zeigt mir, dass offensichtlich nur bestimmte Transponderfrequenzen betroffen sind, denn hier läuft bereits seit mehreren Minuten alles sauber durch: Nun meine Frage, woran das liegen könnte? Da der Fehler beim Tuner mitwandert bzw. sich nur auf bestimmte Frequenzen beschränkt, tippe ich selbst auf ein defektes LNB? Oder wo wäre der Fehler eurer Meinung nach zu suchen?