Jump to content

Problem mit gleichzeitiger Aufnahme von mehreren RTSP Geräten


CaptureKing

Recommended Posts

Hallo

Ich habe in meinem DMS 3 RTSP Geräte (Fritzbox Cable) und ein USB DVB-C Empfänger mit CI am laufen.

Also insgesamt vier Geräte.

Starte ich drei Aufnahmen die nur die drei RTSP Geräte benötigen, da es sich nur um unverschlüsselte Sende handelt

geht alles gut. Starte ich aber zuerst eine Aufnahme von einem verschlüsselten Sender, die nur über den USB DVB-C

empfangbar ist, geht nur noch eine weitere Aufnahme über ein RTSP Gerät. Also wie folgt:

12:00 RTSP Gerät 1: Aufnahme Das Erste HD -> Nimmt auf

12:05 RTSP Gerät 2: Aufnahme ZDF HD -> Nimmt auf

12:10 USB DVB-C : Aufnahme SAT.1 HD -> Nimmt auf

 

12:00 USB DVB-C : Aufnahme SAT.1 HD -> Nimmt auf

12:05 RTSP Gerät 1: Aufnahme Das Erste HD -> Nimmt auf

12:10 RTSP Gerät 2: Aufnahme ZDF HD  -> geht nicht

 

Also läuft gerade eine Aufnahme von dem USB DVB-C Gerät funktioniert nur noch ein RTSP Gerät.

Vielleicht kann mir ja jemand weiter helfen.

support.zip

Edited by CaptureKing
Link to comment

Laut svcdebug.log kommt es im Media Server zu keinem Fehler. Es sieht alles bestens aus, bis auf die Tatsache, dass er vom RTSP Gerät 2 schlicht keine verwertbaren Daten bekommt, die er aufnehmen könnte.

 

Besteht die Möglichkeit, dass dein USB-Gerät auf irgendeine Weise die Fritzbox beeinflusst? Zum Beispiel über das Antennenkabel oder die Dose? Falls ja, wäre es vielleicht einen Versuch wert, während einer Aufnahme mit dem USB-Gerät dessen Antennenstecker abzuziehen (ohne die Aufnahme abzubrechen) und dann probeweise eine Aufnahme über das 2. RTSP-Gerät zu starten.

 

Link to comment

@ Griga

Danke für die schnelle Antwort. Aber eine gegenseitige Beeinflussung von USB DVB-C Gerät und Fritzbox ist absolut auszuschließen.

Der Empfänger steht im ersten Stock und die FB im Keller. Und der beschrieben Fehler trat auch schon auf als ich statt der aktuell verwendeten TechnoTrend TT-connect CT2-4650 eine TechnoTrend TT budget C-1501 PCI Karte verwendete. 

Das Problem liegt nachdem ich jetzt noch einen Versuch gestartet habe definitiv ausschließlich am DMS.

Ich konnte obwohl der DMS nur noch ein Programm von der FB aufnehmen konnte noch den DVBViewer auf dem gleichen Rechner auf dem der DMS läuft starten der problemlos von der FB noch ein weiteres Programm empfangen hat. Die ersten beiden Streams in der FB sind vom DMS und der dritte vom DVBViewer. Und laut FB ist ja auch alles in Ordnung. Die FB hat wie erwartet drei Clients aber im DMS wird nur ein Stream verarbeitet.

dms.jpg

fb.jpg

Link to comment
vor 1 Stunde schrieb CaptureKing:

Aber eine gegenseitige Beeinflussung von USB DVB-C Gerät und Fritzbox ist absolut auszuschließen.

 

Ein rätselhafter Fall, der wohl einige kriminalistische Energie erfordert. Dass ein virtuelles Netzwerkgerät vom DMS verursacht keine Daten mehr liefert, wenn eine DVB USB-Box gleichzeitig in Betrieb ist, erscheint mir auch ziemlich unwahrscheinlich.

 

Passiert das nur, wenn du mit der USB Box einen verschlüsselten Sender empfängst? Um das zu probieren, müsstest du die Box mit der Maus in der Hardwareliste an die zweite Position schieben, so dass sie bei einer zweiten Aufnahme eines unverschlüsselten Senders anstelle des zweiten RTSP-Gerätes zum Zuge kommt.

 

Ich werde bei Gelegenheit probieren, das nachzuvollziehen, kann es jedoch mangels Kabelanschluss nur mit Satellit als Quelle und einem zweiten DMS auf einem anderen PC als Sat>IP-Server durchführen.

 

Link to comment

P.S. Von Interesse wäre auch, was passiert, wenn das zweite (nicht funktionierende) RTSP-Netzwerkgerät nicht durch eine Aufnahme verwendet wird, sondern von einem DMS-Client, z.B. dem DVBViewer.

 

In deiner Konfiguration solltest du für einen sauberen Betrieb den DVBViewer ohnehin als DMS Client konfigurieren und ihn nicht direkt auf die Fritzbox oder DVB-Hardware zugreifen lassen, weil sonst Probleme drohen. Siehe im DVBViewer Hilfe -> Media Server Wizard.

 

Ohne solche Versuche, die vielleicht weitere Aufschlüsse geben,  kann man der Lösung des Problems wohl nicht näher kommen.

 

Link to comment

Ich habe jetzt mal folgendes Szenario probiert:

1.) unverschlüsselte Aufnahme auf RTSP Gerät 1 gestartet -> klappt

2.) unverschlüsselte Aufnahme auf USB Gerät gestartet -> klappt

3.) unverschlüsselte Aufnahme auf RTSP Gerät 2 gestartet -> geht nicht

 

und auch folgendes:

1.) unverschlüsselte Aufnahme auf RTSP Gerät 1 gestartet -> klappt

2.) unverschlüsselte Aufnahme auf USB Gerät gestartet -> klappt

3.) 2. RTSP Gerät wird für DVBViewer verwendet - > klappt

4.) unverschlüsselte Aufnahme auf RTSP Gerät 3 gestartet -> geht nicht

 

Link to comment

Also liegt es nicht an der Verschlüsselung. Das wäre ein Indiz dafür gewesen, dass etwas im PC oder wahrscheinlich im DMS schiefläuft. Die Fritzbox weiß davon ja nichts, sondern liefert einfach nur Daten über das Netzwerk.

 

Den zweiten Test könnte man so interpretieren: Nach Beginn der Verwendung des USB-Gerätes lässt sich nur ein weiteres RTSP-Gerät verwenden, keines darüber hinaus. Alle, die der DMS bereits vorher initialisiert hat, scheinen von dem Effekt nicht betroffen zu sein. Allerdings könntest du noch Schritt 3 und 4 vertauschen, um zu ermitteln, ob es an der Aufnahme liegt.

 

Im Moment wüsste ich noch nicht, wo ich im DMS Code nach einer Ursache suchen könnte. Die einzige Chance ist, ein Muster beim Auftreten des Problems zu erkennen, dass auf die Ursache schließen lässt. Beachte bei solchen Tests, dass der DMS für zwei Sender von der gleichen Frequenz nur ein Gerät verwendet. Imk Zweifelsfall immer auf der Statusseite des Webinterface nachschauen...

 

Link to comment

Dieser folgende Fall funktioniert auch nicht:

1.) unverschlüsselte Aufnahme auf RTSP Gerät 1 gestartet -> klappt

2.) unverschlüsselte Aufnahme auf USB Gerät gestartet -> klappt

3.) unverschlüsselte Aufnahme auf RTSP Gerät 2 gestartet -> geht nicht 

4.) 3. RTSP Gerät wird für DVBViewer verwendet - > klappt

Link to comment

Es scheint etwas damit zu tun zu haben, dass es sich um eine Aufnahme handelt. Die Regel könnte demnach lauten: Wenn eine Aufnahme mit dem USB-Gerät läuft, kann danach nur eine Aufnahme mit einem RTSP-Gerät erfolgreich starten, wenn noch keine andere Aufnahme mit einem RTSP-Gerät läuft. Ein Client anstelle der scheiternden Aufnahme erhält jedoch erfolgreich einen Stream.

 

Das trifft auf alle von dir geschilderten Abläufe zu. Ich stelle sie hier noch mal zusammen:

 

Spoiler

 

12:00 RTSP Gerät 1: Aufnahme Das Erste HD -> Nimmt auf

12:05 RTSP Gerät 2: Aufnahme ZDF HD -> Nimmt auf

12:10 USB DVB-C : Aufnahme SAT.1 HD -> Nimmt auf

 

12:00 USB DVB-C : Aufnahme SAT.1 HD -> Nimmt auf

12:05 RTSP Gerät 1: Aufnahme Das Erste HD -> Nimmt auf

12:10 RTSP Gerät 2: Aufnahme ZDF HD  -> geht nicht 

 

1.) unverschlüsselte Aufnahme auf RTSP Gerät 1 gestartet -> klappt

2.) unverschlüsselte Aufnahme auf USB Gerät gestartet -> klappt

3.) unverschlüsselte Aufnahme auf RTSP Gerät 2 gestartet -> geht nicht

 

1.) unverschlüsselte Aufnahme auf RTSP Gerät 1 gestartet -> klappt

2.) unverschlüsselte Aufnahme auf USB Gerät gestartet -> klappt

3.) 2. RTSP Gerät wird für DVBViewer verwendet - > klappt

4.) unverschlüsselte Aufnahme auf RTSP Gerät 3 gestartet -> geht nicht

 

1.) unverschlüsselte Aufnahme auf RTSP Gerät 1 gestartet -> klappt

2.) unverschlüsselte Aufnahme auf USB Gerät gestartet -> klappt

3.) unverschlüsselte Aufnahme auf RTSP Gerät 2 gestartet -> geht nicht 

4.) 3. RTSP Gerät wird für DVBViewer verwendet - > klappt

 

 

Beim ersten (obersten) Ablauf frage ich mich, ob die als dritte gestartete Aufnahme mit dem USB-Gerät vielleicht unbemerkt eine der Aufnahmen mit einem RTSP-Gerät abgebrochen hat - dann würde die Regel nämlich einfach lauten "Wenn eine Aufnahme mit der USB Box läuft, kann nur noch eine weitere mit einem RTSP-Gerät laufen". Hast du die Aufnahmen auf Vollständigkeit geprüft, d.h. waren sie so lang wie erwartet?

 

Wenn eine Regelmäßigkeit bekannt ist, kann ich sie bei einem Test gezielt überprüfen, anstatt blind herumzuprobieren. Allerdings muss ich dazu dem DMS erst beibringen, seinesgleichen als Server auf einem anderen PC nicht mehr als seinesgleichen zu erkennen, damit es wenigstens ein bisschen ähnlich wie mit der Fritzbox ist. ;)

 

 

Um die Ab

Link to comment

Nein mit Aufnehmen hat das Problem nichts zu tun sondern ausschließlich mit dem Empfang eines Signals vom USB DVB Gerät egal ob es als Aufnahme verwendet wird oder an einen DVBViewer weitergeleitet wird.

1.) DVBViewer empfängt TV Signal von DMS - DMS bekommt Signal von USB Gerät

2.) DMS Aufnahme auf RTSP Gerät 1 gestartet klappt

3.) DMS Aufnahme auf RTSP Gerät 2 gestartet klappt nicht

4.) DVBViewer Client beendet -> kein Empfang von USB Gerät mehr im DMS

5.) DMS Aufnahme auf RTSP Gerät 2 fängt an zu funktionieren

 

Link to comment
vor einer Stunde schrieb CaptureKing:

Nein mit Aufnehmen hat das Problem nichts zu tun sondern ausschließlich mit dem Empfang eines Signals vom USB DVB Gerät egal ob es als Aufnahme verwendet wird oder an einen DVBViewer weitergeleitet wird.

 

Soweit klar. Bislang waren jedoch die "Opfer" immmer von einem RTSP-Gerät versorgte Aufnahmen, nie ein über das RTSP-Gerät versorgter DVBViewer-Client. Das meinte ich.

 

Ich hoffe, ich komme diese Wochenende dazu, das Szenario nachzustellen. In den letzten Tagen war es zeitlich etwas eng.

 

Link to comment

So sieht es hier aus:

 

Zwischenablage01.png

 

RTSP Server ist ein DMS 2.1.4 auf einem PC unter Windows 7 mit drei Sat-Karten, d.h. es sind dort drei Tuner verfügbar. Er wurde so konfiguriert, dass er von Clients aus der DVBViewer-Familie übertragene spezielle Informationen ignoriert, also so tut, als ob er es mit irgendwelchen anderen 0815-Clients zu tun hat.

 

Der Client-DMS 2.1.4 läuft auf einem anderen PC unter Windows 10 mit einer TBS USB Box mit CI für Sat-Empfang. Die Aufnahmen wurden in der folgenden Reihenfolge gestartet: ORF  (verschlüsselt),  Das Erste, ZDF. Alle drei Aufnahmen funktionieren, wie man sieht.

 

Es gibt zwar Abweichungen gegenüber deinem Setup (andere Empfangsart, anderer RTSP Server, anderes Fabrikat der USB Box), aber das Experiment zeigt, dass in der Hinsicht kein systematischer Fehler im DMS vorliegt, der in einer solchen Konstellation die zweite Aufnahme über ein RTSP-Gerät immer scheitern lässt.

 

Es hätte mich auch gewundert. Eine DVB USB Box einerseits und ein virtuelles Netzwerk-Gerät andererseits sind programmtechnisch gesehen so unterschiedliche Schienen, dass eine Beeinflussung der geschilderten Art innerhalb des DMS nur schwer vorstellbar ist. Damit bleibt die große Frage: Auf welche Weise entsteht der Zusammenhang dann???

 

Link to comment

Jetzt weiß ich, woran es höchstwahrscheinlich liegt  - es fehlte nur die Erinnerung an einen früheren Fall, in dem Aufnahmen im DVBViewer betroffen war. Allerdings nützt es dir nichts, da es einen Fix von AVM erfordert.

 

Kurz zusammengefasst: Die Fritzbox liefert nicht alle vom DMS/DVBViewer angeforderten Daten. Dies konnte ein Anwender mit einem (nur mit dem DVBViewer nutzbaren)  Diagnosetool verifizieren. Es wirkt sich auf die Wiedergabe im DVBViewer meistens nicht aus, führt aber dazu, dass Aufnahmen nicht starten. Deshalb waren bei dir nie DVBViewer Clients betroffen. Mit anderen Servern tritt das Problem nicht auf.

 

Das fehlende Element gehört zu den sogenannten SI-Daten (Service Information) bzw. zum senderseits erzeugten Inhaltsverzeichnis des gelieferten Datenstroms. Bei der Live-Wiedergabe kann der DVBViewer sich mit Angaben aus seiner Senderliste helfen, sofern sie dort richtig vorliegen. Bei Aufnahmen ist es jedoch zwingend erforderlich, dass die SI-Daten mit auf die Platte geschrieben werden - später beim Abspielen besteht ja kein Bezug zur Senderliste mehr. Deshalb wartet der DMS auf das Eintreffen dieser Daten, bevor er Video und Audio schreibt  - bei dir in den geschilderten Fällen vergeblich.

 

Es ist bislang unklar, warum die Fritzbox die Daten in bestimmten Fällen liefert und in anderen nicht. Womöglich reichen kleine zeitliche Verschiebungen im Ablauf, um das Problem auszulösen oder zu verhindern. Bei dir macht offenbar der gleichzeitige Betrieb der USB Box und die Ausführung mehrerer Aufnahmen den Unterschied aus.

 

Da ist nun guter Rat teuer. Wenn du mit dem Problem beim AVM-Kundensupport mit Bezugnahme auf diesen Post aufläufst, wird dieser womöglich nicht verstehen, dass ein Fehler in der Server-Implementation der Fritzboxen vorliegt. Sowas lässt sich am besten zwischen Entwicklern (er)klären.  Die Frage ist, wie man den Support davon überzeugt, dass ein solcher Dialog erforderlich ist. Ich werde mal Christian (Hackbart) fragen, ob er eine Chance sieht, den Kontakt auf Firmenebene herzustellen.

 

Link to comment

Zuerst einmal vielen Dank für die vielen Mühen, die du dir wegen des Problems gemacht hast. Und so wie es aussieht muss ich wohl mit dem Problem leben, da AVM wohl nicht so schnell reagieren wird wenn sie denn überhaupt reagieren.

Link to comment

Es gibt Geräte, die direkt nach der Initialisierung etwas "stottern" und ein paar Diskontinuitäten erzeugen, aber danach nicht mehr.

 

Die alte TBS 5980 CI Box ist allerdings immer für ein paar Diskontinuitäten gut. ;) Ich benutze sie nur für Testzwecke, nie für "wirkliche" Aufnahmen.

 

@CaptureKing: Es gibt inzwischen eine neue Vermutungen hinsichtlich des hier behandelten Problems. Könntest du noch Tests durchführen?

 

Link to comment
vor 7 Stunden schrieb CaptureKing:

Was soll ich denn noch testen?

 

Ich habe inzwischen den Verdacht, dass der Sat>IP Server in der Fritzbox Requests unter bestimmten zeitlichen Bedingungen nicht in der Reihenfolge verarbeitet, in der sie der DMS sendet. Beim Start einer Aufnahme folgen zum Beispiel Requests der folgenden Art in wenigen Millisekunden Abstand aufeinander:

 

PLAY rtsp://[IP-Adresse]:[Port]?addpids=18&delpids=0
PLAY rtsp:///[IP-Adresse]:[Port]?addpids=201,202,0,200,204,17

 

In der ersten wird PID 0 abbestellt, in der zweiten zusammen mit anderen Daten neu bestellt. Wenn nun der Server die erste Request nach der zweiten verarbeitet, wird PID 0 letztendlich abbestellt! Dies würde erklären, warum bei den von der Fritzbox gesendeten Daten gerade die PAT mit PID 0 fehlt.

 

Dagegen kann man gezielt etwas tun, um die Vermutung zu verifizieren und das Problem zu beheben. Du müsstest mit DMS-Testversionen, die du via PM erhälst, probieren, ob das Problem damit weiterhin auftritt.

 

Link to comment

Für den nächsten Versuch brauchst du keine Testversion.

 

Wenn du die Datei svchardware.xml aus dem config-Unterverzeichnis deines Konfigurationsordners mit einem Texteditor öffnest, siehst du in jeder Section für RTSP-Geräte eine Zeile

 

<entry name="Wait">0</entry>

 

Setze die Einträge probeweise alle auf 50 oder vielleicht sogar 100. Der DMS muss währenddessen gestoppt sein.

 

Der Tweak veranlasst den DMS, nach jedem Absenden einer Request an den Server eine Pause von X Millisekunden einzulegen und verlangsamt so die Kommunikation künstlich. Die Einstellung stamm von Lars, dem verstorbenen Erfinder des Recording Service. Offenbar musste er sich damals aus irgendeinem Anlass damit befassen, dass Requests zu schnell aufeinander folgen. Näheres ist darüber nicht bekannt, aber vIelleicht hilft die Bremse ja in unserem Fall.

 

Link to comment

Dann mal wieder eine Testversion per PM - soweit deine Geduld reicht :) Das Problem ist ziemlich hartnäckig. Bislang haben wir für so etwas meistens eine Lösung gefunden. Mitunter hat es nur ein paar Monate gedauert ;)

 

Ich stelle mal probeweise die Art der Requests um. Bislang wurden die Streams (PIDs) differentiell mit addpids=.. und delpids=... bestellt / abgewählt, wenn welche hinzukamen / nicht mehr gebraucht wurden. Jetzt beschränke ich den DMS auf absolute Angaben mit pids=..., d.h. jede Request gibt erneut alle benötigten Streams an. Vielleicht schmeckt das der Fritzbox besser.

 

Link to comment

Sorry, ich bin die letzten Tage nicht dazu gekommen, weiter an der Sache zu basteln, denke aber noch drüber nach. Das letzte Wort ist in der Hinsicht noch nicht geschrieben!

 

Dass Änderungen der Requests überhaupt keinen Einfluss auf das Ergebnis haben, hätte ich so nicht erwartet. Es war ziemlich naheliegend, dort die Ursache zu suchen. Aber es sieht so aus, als wäre ich damit auf der falschen Fährte. Ein neuer Ansatz muss her... wenn ich einen finde, melde ich mich wieder.

 

Link to comment

Hallo,

 

dass Problem mit gleichzeitigen Aufnahme mehrere Stream konnte ich bei mir nicht nachvollziehen.

Habe 4 Timer erstellt:

1. Sender von der FB

2. Sender von der FB

3. Sender eines anderen Sat>Ip servers

4. Sender von der FB

 

alle 4 Timer haben aufgenommen!!

 

Habe aber was anderes festgestellt, ob es mit dem Problem hier zusammen hängt kann ich nicht beurteilen:

Sat>Ip Viewer Mac

- Sendersuchlauf funktionier  

1.  wenn ich nach Start des Viewer ein Programm mit TeleText aufrufe, habe ich KEIN Bild und Ton (in der FB wird der sender im Tuner angezeigt), nach Wechsel auf einem Pr. OHNE TeleText, erscheint Bild und Ton

2. wenn ich nach Start des Viewer ein Programm ohne TeleText aufrufe, habe ich Bild und Ton und kann alle Prg. sehen

Sender Ohne TeleText

Spoiler

OPTIONS rtsp://192.168.113.2:554/ RTSP/1.0
CSeq: 1

RTSP/1.0 200 OK
Public: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN
CSeq: 1

SETUP rtsp://192.168.113.2:554/?freq=138&msys=dvbc&sr=6900&specinv=0&mtype=256qam RTSP/1.0
CSeq: 2
Transport: RTP/AVP;unicast;client_port=52002-52003

RTSP/1.0 200 OK
CSeq: 2
Session: 47;timeout=60
Transport: RTP/AVP;unicast;client_port=52002-52003;source=192.168.113.2;server_port=5000-5001
com.ses.streamID: 47

PLAY rtsp://192.168.113.2:554/stream=47?pids=18,0,543,544,260 RTSP/1.0
CSeq: 3
Session: 47

RTSP/1.0 200 OK
CSeq: 3
Session: 47
RTP-Info: url=rtsp://192.168.113.2/stream=47

PLAY rtsp://192.168.113.2:554/stream=47?pids=18,0 RTSP/1.0
CSeq: 4
Session: 47

RTSP/1.0 200 OK
CSeq: 4
Session: 47
RTP-Info: url=rtsp://192.168.113.2/stream=47

PLAY rtsp://192.168.113.2:554/stream=47?pids=0 RTSP/1.0
CSeq: 5
Session: 47

RTSP/1.0 200 OK
CSeq: 5
Session: 47
RTP-Info: url=rtsp://192.168.113.2/stream=47

PLAY rtsp://192.168.113.2:554/stream=47?pids=18,0,543,544,260 RTSP/1.0
CSeq: 6
Session: 47

RTSP/1.0 200 OK
CSeq: 6
Session: 47
RTP-Info: url=rtsp://192.168.113.2/stream=47

Sender mit TeleText

Spoiler

OPTIONS rtsp://192.168.113.2:554/ RTSP/1.0
CSeq: 1

RTSP/1.0 200 OK
Public: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN
CSeq: 1

SETUP rtsp://192.168.113.2:554/?freq=114&msys=dvbc&sr=6900&specinv=0&mtype=256qam RTSP/1.0
CSeq: 2
Transport: RTP/AVP;unicast;client_port=52014-52015

RTSP/1.0 200 OK
CSeq: 2
Session: 46;timeout=60
Transport: RTP/AVP;unicast;client_port=52014-52015;source=192.168.113.2;server_port=5000-5001
com.ses.streamID: 46

PLAY rtsp://192.168.113.2:554/stream=46?pids=18,558,553,554,0,261 RTSP/1.0
CSeq: 3
Session: 46

RTSP/1.0 200 OK
CSeq: 3
Session: 46
RTP-Info: url=rtsp://192.168.113.2/stream=46

PLAY rtsp://192.168.113.2:554/stream=46?pids=18,558 RTSP/1.0
CSeq: 4
Session: 46

RTSP/1.0 200 OK
CSeq: 4
Session: 46
RTP-Info: url=rtsp://192.168.113.2/stream=46

PLAY rtsp://192.168.113.2:554/stream=46?pids=558 RTSP/1.0
CSeq: 5
Session: 46

RTSP/1.0 200 OK
CSeq: 5
Session: 46
RTP-Info: url=rtsp://192.168.113.2/stream=46

PLAY rtsp://192.168.113.2:554/stream=46?pids=18,558,553,554,0,261 RTSP/1.0
CSeq: 6
Session: 46

RTSP/1.0 200 OK
CSeq: 6
Session: 46
RTP-Info: url=rtsp://192.168.113.2/stream=46

PLAY rtsp://192.168.113.2:554/stream=46?pids=18,558 RTSP/1.0
CSeq: 7
Session: 46

RTSP/1.0 200 OK
CSeq: 7
Session: 46
RTP-Info: url=rtsp://192.168.113.2/stream=46

PLAY rtsp://192.168.113.2:554/stream=46?pids=558 RTSP/1.0
CSeq: 8
Session: 46

RTSP/1.0 200 OK
CSeq: 8
Session: 46
RTP-Info: url=rtsp://192.168.113.2/stream=46

PLAY rtsp://192.168.113.2:554/stream=46?pids=18,558,553,554,0,261 RTSP/1.0
CSeq: 9
Session: 46

RTSP/1.0 200 OK
CSeq: 9
Session: 46
RTP-Info: url=rtsp://192.168.113.2/stream=46

OPTIONS rtsp://192.168.113.2:554/ RTSP/1.0
CSeq: 10
Session: 46

RTSP/1.0 200 OK
Public: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN
CSeq: 10
Session: 46

aufgezeichnet mit Wireshark (nur TCP)

 

wenn nicht relevant löschen oder nach Sat>Ip viewer mac verschieben!

 

Gruß lsby

Link to comment

Danke für die Hinweise.

 

In den Wireshark-Aufzeichnungen kann ich nichts erkennen, was den Bild/Tonausfall bei Sendern mit Teletext erklärt. Im wesentlichen legt der Client ja via TCP nur die Senderparameter für das Tunen fest und programmiert die PID-Filter des Servers, d.h. bestimmt, welche Anteile vom gesamten Transportstrom des Transponders durchgereicht werden sollen.

 

Allerdings kenne ich mich mit den Abläufen im Sat>IP Viewer nicht ausreichend aus, um wirklich beurteilen zu können, ob laut Aufzeichnung alles nach Plan läuft. Außerdem weiß ich nicht, welche Elemente (PMT, Video, Audio, Teletext...) bei den Sendern welche PIDs haben (kann man im DVBViewer Senderlisten-Editor oder in einem INI-Export der Sender sehen). Deutlich wird für mich nur, dass das erste PLAY Kommando  beim Sender ohne Teletext 5 PIDs setzt, also PAT (0), EIT (18) für den EPG, dazu drei senderspezifische PIDs für PMT, Video, Audio

 

PLAY rtsp://192.168.113.2:554/stream=47?pids=18,0,543,544,260 RTSP/1.0

 

und beim Sender mit Teletext 6 PIDs, weil noch die für den Teletext hinzukommt:

 

PLAY rtsp://192.168.113.2:554/stream=46?pids=18,558,553,554,0,261 RTSP/1.0

 

Da macht der Client nichts Böses. Und wieso sollte die eine zusätzliche PID den Fritzbox-Server aus dem Tritt bringen? Aufschlussreich wäre, was der Server daraufhin dem Client via UDP liefert, aber da steht man mit Wireshark wohl auf verlorenem Posten, weil es sich um erhebliche Datenmengen handelt.

 

Gemeinsam ist allen bislang berichteten Problemen mit der Fritzbox, dass sie nur mit der Fritzbox als Sat>IP-Server auftreten, und zwar in Abhängigkeit von Bedingungen, die bei jedem Anwender anders sind und in keinem erkennbaren ursächlichen Zusammenhang mit der Fritzbox stehen. Die Sache ist ein ziemliches Rätsel.

 

Link to comment

Hallo,

 

habe nochmals was mit TransEdit probiert:

 

 rtsp://192.168.113.2:554/?avm=1&freq=114&bw=8&msys=dvbc&mtype=256qam&sr=6900&specinv=0&pids=18,558,553,554,0,261

 

als TS-Stream aufgerufen 1406781937_Bildschirmfoto2019-04-02um18_25_17.png.914b896957e2723b7d9c795a6676571c.png

 

es fehlt PAT PIT = 0 !!! kein Bild im Preview 

Ist es erforderlich die pids in aufsteigender Reihenfolge einzugeben? wenn ich  pids=0,18,558,553,554,X,261 eingebe, funktioniert es! (Bild im Preview)

Ist dies ein Fehler in der FB?

Wenn ich diesbezüglich noch was Testen soll, bitte Melden.

 

Grup lsby  

Bildschirmfoto 2019-04-02 um 18.21.41.png

Link to comment
vor 4 Stunden schrieb lsby:

Ist es erforderlich die pids in aufsteigender Reihenfolge einzugeben?

 

Laut Sat>IP-Spezifikationen nicht. Mit allen anderen Sat>IP-Servern funktioniert es.

 

vor 4 Stunden schrieb lsby:

Ist dies ein Fehler in der FB? 

 

Womöglich hast du das Rätsel gelöst. Habe gerade wenig Zeit und komme drauf zurück.

 

Link to comment
vor 21 Stunden schrieb lsby:

habe nochmals was mit TransEdit probiert:

 

Das war eine sehr gute Idee. Der TransEdit Analyzer bildet ja ohne Umschweife ab, was der Server als Reaktion auf die verwendete RTSP URL sendet, ohne dass clientseitig  komplizierte Aufnahme- oder Wiedergabe-Mechanismen beteiligt sind. Es zeigt, dass hier nicht der Client irgendetwas vermurkst, sondern die Fritzbox das Problem mit der fehlenden PAT verursacht.

 

Zu testen wäre noch,, ob der Server die PAT verfälscht, so dass der Client sie verwirft, weil ihre Prüfsumme nicht mehr stimmt. Dazu einfach in TransEdit -> Settings -> General -> Drop SI table sections with wrong CRC ausschalten, das Analyzer-Fenster neu öffnen und schauen, ob die PAT weiterhin fehlt.

 

Außerdem wäre von Interesse, ob andere Besitzer einer Fritzbox mit Sat>IP Server für DVB-C (z.B. @CaptureKing) das Ergebnis reproduzieren können. Ich gebe deshalb die erforderlichen Schritte an ( @lsby: gegebenenfalls korrigieren, falls du etwas ganz anders gemacht hast):

  1. Die aktuelle TransEdit-Version aus dem Download-Bereich herunterladen, TransEdit.exe im DVBViewer-Installationsordner speichern (wo sich DVBViewer.exe befindet).
  2. Von der Fritzbox eine M3U-Senderliste mit RTSP URLs herunterladen . Die enthaltenen URLs sollten ähnlich aussehen wie die von lsby verwendete.
  3. TransEdit starten und die M3U-Liste mit der Maus in das TransEdit-Hauptfenster ziehen. Dort sollten auf der rechten Seite sämtliche URLs als Listenansicht erscheinen.
  4. Auf der rechten Seite des TransEdit-Haupfensters eine der URLs selektieren, dann auf Analyze klicken. Das Analyzer-Fenster zeigt nun die vom Server gelieferten Streams an.
  5. Das Analyzer-Fenster schließen, die URL in der gleichnamigen Eingabezeile so ändern, dass die 0 in der auf &pids=... folgenden Liste nicht am Anfang, sondern mehr am Ende steht (bei lsby war es die vorletzte Position). Die Änderung mit dem rechten (!) Apply-Button übernehmen, dann erneut den Analyzer drauf loslassen: Zeigt er die PAT an, oder fehlt sie nun?
vor 21 Stunden schrieb lsby:

Ist es erforderlich die pids in aufsteigender Reihenfolge einzugeben?

 

Alle Beispiele in den Sat>IP-Spezifikationen geben die pids in aufsteigender Reihenfolge an, und wahrscheinlich auch die URLs in der M3U-Senderliste der Fritzbox. Es ist aber nirgendwo festgelegt, dass das so sein muss! Die Fritzbox verarbeitet die pids ja auch in anderer Reihenfolge, nur die PAT mit PID 0 scheint dabei gelegentlich aus ungeklärter Ursache unter die Räder zu kommen.

 

Bei lsby, CaptureKing und anderen funktionieren Aufnahmen im Prinzip, aber unter bestimmten ungeklärten Bedingungen dann nicht. Da ist wohl niemand mit der Fritzbox als Server auf der sicheren Seite ;) CaptureKing hat bereits DMS-Testversionen mit verschiedenen Modifikationen der PID-Liste erfolglos probiert. Ich bin allerdings noch nicht auf die Idee gekommen, die Reihenfolge der PIDs umzustellen und werde jetzt überlegen, wie man das im DVBViewer/DMS am besten realisiert.

 

Ich vermute immer noch, dass bei der Sache ein  "Zufallsfaktor" im Spiel ist, z.B. bestimmte Timing-Bedingungen, unter denen das Problem auftritt oder nicht. Von daher könnte es sein, dass das obige Experiment mit TransEdit bei anderen anders ausgeht als bei lsby. Es wäre gut, wenn das überprüft würde, bevor Christian erneut bei AVM mit "so lässt sich das Problem reproduzieren" vorstellig wird.

 

Link to comment

@CaptureKing: Ich könnte jetzt eine DMS-Version zur Verfügung stellen, die lsbys Befund berücksichtigt, indem sie sich auf absolute Angaben mit pids=... beschränkt (also kein addpids und delpids verwendet) und die Liste der PIDs aufsteigend sortiert, so dass PID 0 immer am Anfang steht.

 

Es wäre jedoch sinnvoller, wenn du erst mal den in meinem vorherigen Post beschriebenen Ablauf mit TransEdit durchführst. Da kann man sofort sehen, wie sich eine Modifikation der PID-Liste auswirkt.

 

Link to comment
vor 2 Stunden schrieb CaptureKing:

Und das ist die Variante mit der 0 an vorletzter Stelle

 

Du kannst das Ergebnis von lsby reproduzieren. Sehr gut. AVM wird also dran glauben müssen - an den Bug natürlich. :)

 

Fragt sich noch, ob der Befund auch auf deine Probleme mit dem DMS anwendbar ist - das ist strukturell eine andere Geschichte als der TransEdit Analyzer. Es gibt die in meinem vorherigen Post beschriebene Testversion via PM...

 

BTW: Unter welchem (exakten) Namen wird der Fritzbox-Server in den Einstellungen des RTSP-Gerätes erkannt? Falls es einen speziellen Code-Zweig für AVM geben muss, wäre eine automatische Erkennung nicht schlecht.

 

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...