streamdev-server-plugin 0.5.2: Lange Umschaltzeiten

Hallo,

ich setze seit einigen Jahren vdr 1.6.0 ein und habe mich endlich aufgerafft, einen vdr Server ohne Grafikkarte (headless) in den Keller zu stellen. Der vdr im Wohnzimmer hat keine DVB Karte mehr und ist nur noch Client. Streaming über streamdev läuft fast 1a

Auf dem Server läuft vdr 1.6.0 + streamdev 0.5.2 + dummydevice + weitere Plugins
(vdr Version 1.6.0 wegen "softdevice" Plugin auf dem Client - geht noch nicht mit 2.x)

Problem: Das Umschalten von Kanälen dauert mitunter fünf Sekunden, wenn der VDR Server gerade auch einen Kanal "fernsieht".

In dem alten Thema "streamdev-server-plugin 0.5.1 lnb-sharing und headless server" gibt es den experimentellen "always_suspend" Patch. Dieser löst das Umschaltproblem, schafft jedoch ein Neues: Bei jedem Durchlauf der Hauptschleife in vdr.c wird "LastInteract" zurückgesetzt (vermutlich löst SuspendCtrl eine OSD "Aktion" aus)
-> Damit fährt vdr nicht mehr von selbst runter. Hat mich ein wenig Debugging-Code gekostet das herauszufinden...

Konfiguriere ich den streamdev Server auf "Client darf pausieren" und pausiere einmal die Ausgabe auf dem Server, so ist das Kanalumschalten sehr schnell. Konfiguriere ich den streamdev Server auf "Immer pausiert", dauert es die oben beschriebenen fünf Sekunden.

Ein Kanalwechsel von Kanal 8 auf Kanal 1 sieht so aus:

Jul 14 00:37:39 vdrmaster vdr: [3296] transfer thread ended (pid=3156, tid=3296)
Jul 14 00:37:39 vdrmaster vdr: [3298] TS buffer on device 1 thread ended (pid=3156, tid=3298)
Jul 14 00:37:39 vdrmaster vdr: [3297] buffer stats: 164688 (7%) used
Jul 14 00:37:39 vdrmaster vdr: [3297] receiver on device 1 thread ended (pid=3156, tid=3297)
Jul 14 00:37:40 vdrmaster vdr: [3156] switching to channel 8
Jul 14 00:37:40 vdrmaster vdr: [3156] buffer stats: 161492 (7%) used
Jul 14 00:37:40 vdrmaster vdr: [3156] info: Kanal nicht verfügbar!
Jul 14 00:37:42 vdrmaster vdr: [3156] switching to channel 1
Jul 14 00:37:42 vdrmaster vdr: [3156] info: Streamen im Gange
Jul 14 00:37:42 vdrmaster vdr: [3350] receiver on device 1 thread started (pid=3156, tid=3350)
Jul 14 00:37:42 vdrmaster vdr: [3349] transfer thread started (pid=3156, tid=3349)
Jul 14 00:37:42 vdrmaster vdr: [3351] TS buffer on device 1 thread started (pid=3156, tid=3351)
Jul 14 00:37:44 vdrmaster vdr: [3300] streamdev-livestreaming thread ended (pid=3156, tid=3300)
Jul 14 00:37:44 vdrmaster vdr: [3299] streamdev-writer thread ended (pid=3156, tid=3299)
Jul 14 00:37:44 vdrmaster vdr: [3170] buffer stats: 165064 (4%) used
Jul 14 00:37:44 vdrmaster vdr: [3352] streamdev-writer thread started (pid=3156, tid=3352)
Jul 14 00:37:44 vdrmaster vdr: [3353] streamdev-livestreaming thread started (pid=3156, tid=3353)
Jul 14 00:37:44 vdrmaster vdr: [3349] video: synced early

Was dabei auffällt: Es kommt zuerst ein "switching to channel 8", sprich er wechselt erneut zum bereits eingestellten Kanal.
Liegt das am "info: Kanal nicht verfügbar" und er wechselt sozusagen auf Kanal 8 zurück?
Vermutlich schaltet er dann im zweiten Anlauf mit Gewalt auf Kanal 1.

Hier der gleiche Kanalwechsel während der Server pausiert ist:

Jul 14 00:55:05 vdrmaster vdr: [3444] streamdev-livestreaming thread ended (pid=3380, tid=3444)
Jul 14 00:55:05 vdrmaster vdr: [3443] streamdev-writer thread ended (pid=3380, tid=3443)
Jul 14 00:55:05 vdrmaster vdr: [3394] buffer stats: 97760 (2%) used
Jul 14 00:55:05 vdrmaster vdr: [3447] streamdev-writer thread started (pid=3380, tid=3447)
Jul 14 00:55:05 vdrmaster vdr: [3448] streamdev-livestreaming thread started (pid=3380, tid=3448)
Jul 14 00:55:05 vdrmaster vdr: [3446] TS buffer on device 1 thread ended (pid=3380, tid=3446)
Jul 14 00:55:05 vdrmaster vdr: [3445] buffer stats: 97384 (4%) used
Jul 14 00:55:05 vdrmaster vdr: [3445] receiver on device 1 thread ended (pid=3380, tid=3445)
Jul 14 00:55:05 vdrmaster vdr: [3449] receiver on device 1 thread started (pid=3380, tid=3449)
Jul 14 00:55:05 vdrmaster vdr: [3450] TS buffer on device 1 thread started (pid=3380, tid=3450)

Interessanterweise protokolliert er hier nichts mehr von "switching channel".

Folgendes habe ich noch herausgefunden: Ohne "dummydevice"-plugin schaltet er schnell um.
Vermutlich kann der Server dann nicht mehr fernsehen. Allerdings kommen dann solche Meldungen,
wenn ich z.B. das OSD über das "vdr-remote" Plugin per telnet aufrufe:

ERROR: no OSD provider available - using dummy OSD!

Damit könnte ich zur Not leben...

Ideen wie man das Verhalten verbessern kann?
Benötigt man mit vdr 1.6.0 noch das "dummydevice" für einen headless Server?

Danke und Gruß,
Thomas

PS: Puh, ganz schön langer Text für meinen ersten Beitrag

Danke für die Willkommensgrüße

Zitat von Copperhead

Warum soll das softdevice Plugin nicht mit VDR 2.0.0 funktionieren?

Das "softdevice" zeigt momentan kein OSD mit vdr 2.x.
Denke da werden noch ein paar Anpassungen nötig sein.

xineliboutput habe ich mir bisher verkniffen, da ich mit "softdevice"
auf einer Matrox G550 + directfb perfekte Halbbilder für den Röhrenfernseher hinbekommen habe.

Zitat

Ich verstehe auch deine Kombination nicht. Du hast VDR-Clients und einen VDR-Server. An dem Server wird aber auch direkt fern geschaut?!

Der Server nimmt nur auf. Jedoch "sieht" der Server intern auch immer einen Kanal, zumindest wenn das dummydevice da ist.
Das lässt sich ja gar nicht vermeiden (ausführliche Erklärung hier), es sei denn die Ausgabe auf dem Server ist pausiert.

Wie gesagt, ohne "dummydevice"-Plugin scheint es ganz ok zu sein. Werde das mal ein paar Tage beobachten.

Gruß,
Thomas

Zitat von DocViper

Der VDR 1.6 braucht für headless imho noch ein dummydevice weil mindestens ein Primary vom VDR erwartet wurde.
Diese Regel ist irgendwann mal gefallen. Deshalb macht das Update auf eine aktuelle Version doppelt Sinn.

Bis jetzt läuft erstaunlicherweise alles ohne dummydevice stabil, heute ein wenig ferngesehen und auch zwei Aufnahmen gemacht.

Zitat von Keine_Ahnung

Naja, wenn der Client für die Ausgabe softdevice (und damit 1.6) benötigt dann darf der Server ja nicht 2.0 sein (wegen geänderten Aufnahmeformat). Und das aktuelle streamdev läuft leider auch nicht mehr mit 1.6.

Exakt

Das alte "softdevice" bringt nach ein paar Minianpassungen einwandfrei ein Bild mit vdr 2.x., nur das OSD fehlt.
Das liegt vermutlich an dem neuen TrueColor OSD Support. Denke das sollte sich noch mit vertretbarem Aufwand anpassen lassen.

Um zum eigentlichen Thema zurückzukommen: Eventuell hat Benutzer schmirl vielleicht noch
eine Idee zu den langen Umschaltzeiten. Wobei es eigentlich fast schon egal ist, ohne
dummydevice scheint alles ok zu laufen.

Gruß,
Thomas

Zitat von Keine_Ahnung

Würdest du die Anpassungen mal hochladen? Ich würde auch gerne mit softdevice auf 2.0 umsteigen.

Wegen dem OSD, evtl. ist ja zufällig per default nen True Color OSD aktiv? Lade mal skinenigma oder ähnliches.

Ich hatte nur quick'n'dirty die i18n Aufrufe des vdr 1.6.0 rausgeworfen, danach hat es kompiliert.
Wollte erstmal sehen, ob es überhaupt klappt.

Wichtig ist allerdings die ffmpeg Version: Die darf nicht zu hoch sein, sonst kommen Threading-Fehlermeldung seitens ffmpeg und Crashes.
Mit Version 0.5.2.1 läuft's bei mir prima. Also noch ne Baustelle

Werde die Tage nach meinem Patch suchen + build-Instruktionen.
Damit konnte ich es dann unter Fedora 19 kompilieren, sprich
ein relativ neuer gcc war auch kein Problem.

Das mit dem truecolor OSD Skin werde ich in dem Zuge auch ausprobieren, guter Tip!

Zitat von schmirl

Hat Dein Server nur eine DVB-Karte? In diesem Fall wäre es egal, ob er mit oder ohne dummydevice läuft.

Der Server hat zwei DVB Karten.

Zitat von schmirl

Zum Umschaltproblem: Wenn bei streamdev-0.5.2 keine Karte für Streaming frei ist und somit Live-TV umgeschaltet werden müsste, wird zunächst versucht, Live-TV auf eine andere Karte zu verlagern. Daher das "switching to channel 8". Erst wenn das fehlschlägt wird Live-TV auf den neuen Kanal umgeschaltet. Die Verzögerung kommt dann wohl von der "Kanal nicht verfügbar"-Meldung. Setze die Anzeigedauer für Meldungen auf dem Server doch mal auf 0 (OSDMessageTime in der setup.conf). Zur Not könntest Du den ersten Umschaltversuch aber auch aus streamdev rauspatchen.

OSDMessageTime stand schon auf 1, ein Wert von 0 macht leider keinen Unterschied.

Der Tip mit dem Live TV war nicht schlecht, ich weiss jetzt wie ich das Problem provozieren kann:

- DVB Karte 1 streamt per VTP an den Client im Wohnzimmer, Kanal 4.
- "Live-TV" auf dem Server steht auch auf Kanal 4
- DVB Karte 2 streamt per HTTP an meinem Rechner, Kanal 12

Sobald ich jetzt am Client umschalte dauert es fünf Sekunden.
Stoppe ich den HTTP Stream, so wird beim nächsten Kanalwechsel
der VDR Client auf die zweite DVB Karte verlagert.

Ich habe in einem anderen Thema gelesen, daß streamdev leider das Live-TV
auf dem Server nicht selbständig beim Plugin-Start in den suspend schicken kann.

Der "always-Suspend" Patch arbeitet fast schon einwandfrei, ausser das
er bei jeden Durchlauf durch den Mainloop das "LastInteract" resettet.
Durch einige isyslog() Aufrufe an den richtigen Stellen bin ich dem
Problem auf die Spur gekommen.

Damit keine OSD-Aktion ausgelöst wird, muss das SuspendCtl
auf "hidden" gestellt werden. Sonst gibt cControl::Control()
einen Wert zurück und die Hauptschleife aktualisiert dadurch
"LastInteract". Das wiederum verhindert das Herunterfahren bei Inaktivität.

Anbei der aktualisierte Patch für Version 0.5.2. Ich hoffe
das bringt auch was für die aktuelle streamdev Version/Entwicklung.

Gruß,
Thomas