Streamdev Umschaltprobleme

MarkusH · 8. Januar 2012

Hallo Leutz,

nachdem mein Server jetzt mit der CineS2 und 4 Tunern läuft, habe ich ein Umschaltproblem am Streamdev-Client festgestellt. Ich hab halt öfter beim Umschalten kein Bild. Beispiel: ARD läuft und ich schalte auf ZDF -> kein Bild. Einmal zurück zu ARD und wieder auf ZDF - jetzt gehts.

Als Ursache hab ich folgenden Eintrag im Log des Clienten ausgemacht:
Jan 8 14:35:56 vdr-cl1 vdr: [1236] Streamdev: Lost connection to 10.10.1.60:2004: Die Wartezeit für die Verbindung ist abgelaufen
Jan 8 14:35:56 vdr-cl1 vdr: [1236] Streamdev: Connected to server 10.10.1.60:2004 using capabilities TSPIDS,FILTERS,PRIO

Der Client ist über WLAN verbunden. Im Log steht dann meist auch:
Jan 8 14:36:55 vdr-cl1 wpa_supplicant[900]: WPA: Group rekeying completed with 00:24:fe:a7:dd:83 [GTK=CCMP]
Jan 8 14:36:55 vdr-cl1 wpa_supplicant[900]: WPA: EAPOL-Key Replay Counter did not increase - dropping packet

Ist dann ein Problem mit dem WLAN? Als der Client noch unter yaVDR 0.3 lief und mit dem "alten" Server verbunden war hatte ich das Problem nicht?!?

Server: yaVDR 0.4 headless mit streamdev-server 0.5.1-git
Konfiguration von streamdev:
streamdev-server.AllowSuspend = 1
streamdev-server.HTTPBindIP = 0.0.0.0
streamdev-server.HTTPServerPort = 3000
streamdev-server.HTTPStreamType = 0
streamdev-server.IGMPBindIP = 0.0.0.0
streamdev-server.IGMPClientPort = 1234
streamdev-server.IGMPStreamType = 0
streamdev-server.MaxClients = 5
streamdev-server.ServerPort = 2004
streamdev-server.StartHTTPServer = 1
streamdev-server.StartIGMPServer = 0
streamdev-server.StartServer = 1
streamdev-server.SuspendMode = 1
streamdev-server.VTPBindIP = 0.0.0.0

Client: yaVDR 0.4 mit streamdev-client 0.5.1-git
streamdev-client.HideMenuEntry = 0
streamdev-client.MaxPriority = 99
streamdev-client.MinPriority = -1
streamdev-client.NumProvidedSystems = 1
streamdev-client.RemoteIp = 10.10.1.60
streamdev-client.RemotePort = 2004
streamdev-client.StartClient = 1
streamdev-client.StreamFilters = 0

Auszug ausm syslog vom Server:
Jan 8 12:46:22 srv-vdr vdr: [1786] streamdev-livestreaming thread ended (pid=974, tid=1786)
Jan 8 12:46:22 srv-vdr vdr: [1785] streamdev-writer thread ended (pid=974, tid=1785)
Jan 8 12:46:22 srv-vdr vdr: [1128] buffer stats: 115620 (3%) used
Jan 8 12:46:22 srv-vdr vdr: [1128] buffer stats: 0 (0%) used
Jan 8 12:46:22 srv-vdr vdr: [1128] buffer stats: 0 (0%) used
Jan 8 12:46:22 srv-vdr vdr: [1128] Streamdev: Setting data connection to 10.10.1.84:41690
Jan 8 12:46:24 srv-vdr vdr: [1128] Streamdev: Accepted new client (VTP) 10.10.1.84:59883
Jan 8 12:46:24 srv-vdr vdr: [1128] client (VTP) 10.10.1.84:39048 has closed connection
Jan 8 12:46:24 srv-vdr vdr: [1128] streamdev-server: closing VTP connection to 10.10.1.84:39048
Jan 8 12:46:24 srv-vdr vdr: [1789] receiver on device 2 thread started (pid=974, tid=1789)
Jan 8 12:46:24 srv-vdr vdr: [1788] streamdev-livestreaming thread started (pid=974, tid=1788)
Jan 8 12:46:24 srv-vdr vdr: [1788] streamdev-livestreaming thread ended (pid=974, tid=1788)
Jan 8 12:46:24 srv-vdr vdr: [1787] streamdev-writer thread started (pid=974, tid=1787)
Jan 8 12:46:24 srv-vdr vdr: [1790] TS buffer on device 2 thread started (pid=974, tid=1790)
Jan 8 12:46:24 srv-vdr vdr: [1787] streamdev-writer thread ended (pid=974, tid=1787)
Jan 8 12:46:24 srv-vdr vdr: [1128] buffer stats: 0 (0%) used
Jan 8 12:46:24 srv-vdr vdr: [1128] buffer stats: 0 (0%) used
Jan 8 12:46:24 srv-vdr vdr: [1790] TS buffer on device 2 thread ended (pid=974, tid=1790)
Jan 8 12:46:24 srv-vdr vdr: [1128] streamdev-server TUNE S19.2E-1-1107-17500: Priority unknown - using 0
Jan 8 12:46:24 srv-vdr vdr: [1128] buffer stats: 0 (0%) used
Jan 8 12:46:24 srv-vdr vdr: [1789] buffer stats: 0 (0%) used
Jan 8 12:46:24 srv-vdr vdr: [1789] receiver on device 2 thread ended (pid=974, tid=1789)
Jan 8 12:46:24 srv-vdr vdr: [1128] streamdev-server TUNE S19.2E-1-1107-17500: Priority unknown - using 0

Auszug ausm Client-Log
Jan 8 12:46:09 vdr-cl1 vdr: [1083] switching to channel 4
Jan 8 12:46:10 vdr-cl1 vdr: [1606] ERROR (device.c,1926): UngÃ¼ltiger Dateideskriptor
Jan 8 12:46:10 vdr-cl1 vdr: [1606] TS buffer on device 24 thread ended (pid=1083, tid=1606)
Jan 8 12:46:10 vdr-cl1 vdr: [1607] buffer stats: 188752 (9%) used
Jan 8 12:46:10 vdr-cl1 vdr: [1607] receiver on device 24 thread ended (pid=1083, tid=1607)
Jan 8 12:46:10 vdr-cl1 vdr: [1691] TS buffer on device 24 thread started (pid=1083, tid=1691)
Jan 8 12:46:10 vdr-cl1 vdr: [1692] receiver on device 24 thread started (pid=1083, tid=1692)
Jan 8 12:46:10 vdr-cl1 vdr: [1692] cVideoRepacker: switching to MPEG1/2 mode
Jan 8 12:46:10 vdr-cl1 vdr: [1692] cVideoRepacker: operating in MPEG1/2 mode
Jan 8 12:46:13 vdr-cl1 vdr: [1690] Text2Skin: channelInfo display update thread ended (pid=1083, tid=1690)
Jan 8 12:46:15 vdr-cl1 vdr: [1693] Text2Skin: channelInfo display update thread started (pid=1083, tid=1693)
Jan 8 12:46:17 vdr-cl1 vdr: [1693] Text2Skin: channelInfo display update thread ended (pid=1083, tid=1693)
Jan 8 12:46:21 vdr-cl1 vdr: [1694] Text2Skin: channelInfo display update thread started (pid=1083, tid=1694)
Jan 8 12:46:22 vdr-cl1 vdr: [1083] switching to channel 5
Jan 8 12:46:22 vdr-cl1 vdr: [1691] ERROR (device.c,1926): UngÃ¼ltiger Dateideskriptor
Jan 8 12:46:22 vdr-cl1 vdr: [1691] TS buffer on device 24 thread ended (pid=1083, tid=1691)
Jan 8 12:46:22 vdr-cl1 vdr: [1692] buffer stats: 121824 (5%) used
Jan 8 12:46:22 vdr-cl1 vdr: [1692] receiver on device 24 thread ended (pid=1083, tid=1692)
Jan 8 12:46:22 vdr-cl1 vdr: [1695] TS buffer on device 24 thread started (pid=1083, tid=1695)
Jan 8 12:46:23 vdr-cl1 vdr: [1083] Streamdev: Lost connection to 10.10.1.60:2004: Die Wartezeit fÃ¼r die Verbindung ist abgelaufen
Jan 8 12:46:24 vdr-cl1 vdr: [1083] Streamdev: Connected to server 10.10.1.60:2004 using capabilities TSPIDS,FILTERS,PRIO
Jan 8 12:46:24 vdr-cl1 vdr: [1695] ERROR (device.c,1926): UngÃ¼ltiger Dateideskriptor
Jan 8 12:46:24 vdr-cl1 vdr: [1695] TS buffer on device 24 thread ended (pid=1083, tid=1695)
Jan 8 12:46:24 vdr-cl1 vdr: [1083] buffer stats: 0 (0%) used
Jan 8 12:46:24 vdr-cl1 vdr: [1083] ERROR: can't set PID 255 on device 24
Jan 8 12:46:24 vdr-cl1 vdr: [1083] Streamdev: Pid 255 not available from 10.10.1.60:2004

Gruß - Markus

Dr Jones · 8. Januar 2012

Habe hier das selbe Problem! Funktioniert bei mir allerdings auch per Lan. Habe die selben Fehlermeldungen. Streamdev ist im Augenblick das Ärgernis schlechthin.
Anzumerken ist vielleicht, daß der Server Powerzapping aushält und immer ein Bild nach einem Kanalwechsel zeigt.

Grüße
Dr Jones

johns · 8. Januar 2012

Ja kenne ich hier mein Post: streamdev-server Timeout bei mehr als zwei Satkarten

Meine Lösung war EPG Scan ausschalten.

schmirl meinte im Plugin Code Timeout auf >10s stellen.

Johns

DonCamillo · 8. Januar 2012

Hallo,

das Problem habe ich auch, ebenfalls über LAN, ebenfalls Twintuner.

johns,
wie kommst Du denn dann an Deine EPG-Daten - externer Provider oder über Deinen 2. Server?

MarkusH · 8. Januar 2012

EPGScan ist bei mir (am Server) sowie aus (EPGScanTimeout = 0) da ich externes EPG nutze. Am Client hole ich dann per EPGsync (auf manuell gestellt) das EPG vom Server.

MarkusH · 8. Januar 2012

Ach noch was: Wenn ich am PC mit vlc schaue, ist mir das übrigens noch nicht passiert dass ich kein Bild bekomme. Liegt aber vermutlich daran, dass sich vlc bei jedem Kanalwechsel neu connectet...

Markus

DonCamillo · 9. Januar 2012

EPG-Scan deaktivieren änderte bei mir auch nichts - habe auf dem Streamdev-Server
- externes EPG installiert
- unter System - Einstellungen - EPG - Zeit bis zur EPG-Aktualisierung auf 0 gesetzt (dito auf dem Client)
- unter System - Einstellungen - DVB - Kanäle aktualisieren auf "nein" gesetzt
- rebootet (dito den Client)

Effekt und Fehlermeldung bleiben leider bestehen, wie im Eingangspost von MarkusH beschrieben.

DonCamillo · 9. Januar 2012

Habe mal nach "TSPIDS,FILTERS,PRIO" gesucht. In einem anderen Thread Link gab es den Hinweis, daß das Deaktivieren der Filterdaten das Problem löst.

Bei mir ist es deaktiviert, laut dem o. g. conf-File auch bei MarkusH (streamdev-client.StreamFilters = 0).

Trotzdem lautet die Meldung im Log:

Zitat

Streamdev: Connected to server 10.10.1.60:2004 using capabilities TSPIDS,FILTERS,PRIO

Eigentlich ein Widerspruch

schmirl · 10. Januar 2012

Dass der Client dem Server die "FILTERS" meldet, auch wenn diese ausgeschaltet sind, könnte man rausoptimieren. Der Client hält sich trotz der irreführenden Meldung an das was konfiguriert ist und öffnet keinen Kanal für die Filter-Daten. Und auch auf dem Server wird nichts ausgelöst, was zu den beschriebenen Problemen führen könnte.

Dreht mal in client/socket.h die Timeouts hoch. Vermutlich sind die SAT-Karten nicht gerade die schnellsten beim Umschalten.

Diff

--- a/client/socket.h
+++ b/client/socket.h
@@ -30,13 +30,13 @@ protected:
           Returns false on failure, setting errno appropriately if it has been
           a system failure. If Expected is zero, returns immediately after
                 sending the command. */
-       bool Command(const std::string &Command, uint Expected = 0, uint TimeoutMs = 1500);
+       bool Command(const std::string &Command, uint Expected = 0, uint TimeoutMs = 10000);
 
        /* Fetch results from an ongoing Command called with Expected == 0. Returns
           true if the response has the code Expected, returning an internal buffer
                 in the array pointer pointed to by Result. Returns false on failure, 
                 setting errno appropriately if it has been a system failure. */
-       bool Expect(uint Expected, std::string *Result = NULL, uint TimeoutMs = 1500);
+       bool Expect(uint Expected, std::string *Result = NULL, uint TimeoutMs = 10000);
 
 public:
        cClientSocket(void);

Alles anzeigen

skippy · 10. Januar 2012

Ich wollte auch mal kurz meine Erfahrungen mit Umschaltproblemen schildern, vielleicht hilft es ja, das Problem einzugrenzen: Bei mir treten sie sowohl beim SD-Client, als auch beim HD-Client über DVB-C auf. Allerdings beobachte ich sie nur, wenn die Kanäle auf demselben Transponder liegen. Dann ist das Bild entweder schwarz oder das Bild vom aktuellen Kanal ist eingefroren (jedoch nicht immer, selten funktioniert es auch). Wechsele ich auf einen Kanal, der auf einen anderen Transponder liegt und gehe dann zurück, ist das Bild da.

Da ich momentan nicht zu Hause bin, kann ich keine Logs liefern. Meine Hardware, siehe Signatur. Über die MLD ist die aktuellste Version vom Streamdev Server und Client installiert.

Viele Grüße skippy

MarkusH · 10. Januar 2012

Zitat von schmirl

Dreht mal in client/socket.h die Timeouts hoch. Vermutlich sind die SAT-Karten nicht gerade die schnellsten beim Umschalten.

Ich denke auch das es mit den Umschaltzeiten zu tun hat. Leider hab ich kein Entwicklungssystem mehr am Laufen. Vielleicht findet sich jemand der das mal einbauen könnte?

Markus

gehlhajo · 10. Januar 2012

Zitat von skippy

Wechsele ich auf einen Kanal, der auf einen anderen Transponder liegt und gehe dann zurück, ist das Bild da.

Lass' mich raten: Du hast das 'Jehova-Plugin' am Start......

skippy · 10. Januar 2012

wenn es so wäre, würde ich es doch hier nicht schreiben.

fnu · 10. Januar 2012

Zitat von schmirl

Dreht mal in client/socket.h die Timeouts hoch. Vermutlich sind die SAT-Karten nicht gerade die schnellsten beim Umschalten.

Meinst Du das reicht aus, das nur bei streamdev zu ändern?

Regards
fnu

decembersoul · 10. Januar 2012

Ich habe diese Änderung seit einiger Zeit am laufen und seit dem keine Probleme mehr. Allerdings habe ich auch noch andere Sachen umgestellt.
Zwar habe ich zZ ein anderes Problem aber das scheint nicht mehr das hier beschriebene zu sein.

schmirl · 11. Januar 2012

skippy: Damit streamdev sauber mit verschlüsselten Kanälen umgehen kann, gibt es zwei Workarounds (beide im README von streamdev beschrieben):
1. CA-ID der Kanäle im Client auf die Device-ID des streamdev-clients stellen. Diese ist meist 9 oder 10 und wird beim Starten des VDR im Log protokolliert ("streamdev-client: got device number ..."). Die CA-ID nicht auf 0 (für unverschlüsselt) stellen. Damit gibt es die beschriebenen Umschaltprobleme!
2. Patch aus den Streamdev-Sourcen anwenden. Entweder vdr-1.6.0-intcamdevices.patch oder vdr-1.6.0-ignore_missing_cam.diff

fnu: Wenn sich das Umschalten der Karten nicht beschleunigen lässt, genügt die Änderung in streamdev-client. Sobald ich Zeit dafür finde, werde ich den Timeout im Setup konfigurierbar machen.

MarkusH · 11. Januar 2012

Zitat von schmirl

Sobald ich Zeit dafür finde, werde ich den Timeout im Setup konfigurierbar machen.

-> Geil, darauf werd ich dann warten (hoffentlich nicht zu lange... )

Markus

decembersoul · 11. Januar 2012

Zitat von schmirl

skippy: Damit streamdev sauber mit verschlüsselten Kanälen umgehen kann, gibt es zwei Workarounds (beide im README von streamdev beschrieben):
1. CA-ID der Kanäle im Client auf die Device-ID des streamdev-clients stellen. Diese ist meist 9 oder 10 und wird beim Starten des VDR im Log protokolliert ("streamdev-client: got device number ..."). Die CA-ID nicht auf 0 (für unverschlüsselt) stellen. Damit gibt es die beschriebenen Umschaltprobleme!
2. Patch aus den Streamdev-Sourcen anwenden. Entweder vdr-1.6.0-intcamdevices.patch oder vdr-1.6.0-ignore_missing_cam.diff

Ich habe bei den Clients einfach in der Channels.conf eingetragen das die Verschlüsselten Sender nicht verschlüsselt sind. Habe da ein Shell Script für.
Dein Workaround klingt aber gut. Beim nächsten Client werde ich mir das mal ansehen.

schmirl · 11. Januar 2012

Zitat von decembersoul

Ich habe bei den Clients einfach in der Channels.conf eingetragen das die Verschlüsselten Sender nicht verschlüsselt sind. Habe da ein Shell Script für.

... welches sich ja leicht dahingehend anpassen ließe, dass anstelle der 0 die Device-Nummer eingetragen wird. Achtung: In der channels.conf müssen Hexadezimal-Zahlen eingetragen werden! Statt z.B. 10 also bitte a eintragen. Über das OSD im Kanäle Menü wird dezimal eingegeben.

DonCamillo · 11. Januar 2012

Nur damit nicht der Eindruck entsteht, daß das Ganze ausschließlich in Verbindung mit verschlüsselten Sendern auftritt: Ich nutze kein Jehova-Plugin und das von MarkusH im ersten Mail beschriebene Problem tritt hier mit unverschlüsselten Sendern auf.

Zitat von schmirl

Vermutlich sind die SAT-Karten nicht gerade die schnellsten beim Umschalten.

Naja, wenn ich am Server ein Frontend aktiviere und lokal umschalte geht es aus meiner Sicht recht zügig - wobei das natürlich ein subjektiver Eindruck sein kann.

Schmirl ist der Experte, insofern harre auch ich gespannt der Dinge, die da kommen...

Streamdev Umschaltprobleme

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema