Primäres Device per SVDRP-Kommando umschalten

  • Hallo zusammen


    Nach der heutigen, kleinen Diskussion übers Umschalten von VDR zu Kodi und den damit verbundenen Problemen, habe ich die benötigten SVDRP-Kommandos zum Umschalten des primären Devices in VDR implementiert - Patch für vdr-2.3.1 ist angehängt. Klaus hat sich grundsätzlich positiv dazu geäussert und will sich die Lösung zu gegebener Zeit genauer anschauen, weshalb ich den Patch mal hier zum Testen teile. Die Funktion ist nicht allzu kompliziert:


    Code
    1. localhost ~ # svdrpsend help lstd
    2. 220 localhost SVDRP VideoDiskRecorder 2.3.1; Fri Feb 12 14:51:24 2016; UTF-8
    3. 214-LSTD
    4. 214- List all available devices. Each device is listed with its name and
    5. 214- whether it's currently the primary device ('P') or it implements a
    6. 214- decoder ('D') and can be used as output device.
    7. 214 End of HELP info
    8. 221 localhost closing connection


    Code
    1. localhost ~ # svdrpsend help prim
    2. 220 localhost SVDRP VideoDiskRecorder 2.3.1; Fri Feb 12 14:51:37 2016; UTF-8
    3. 214-PRIM [ <device> ]
    4. 214- Request VDR to switch primary device to the given device number.
    5. 214- Without option it returns the current active primary device and its name.
    6. 214 End of HELP info
    7. 221 localhost closing connection


    Mit streamdev-client, rpihddevice und dummydevice schaut dass dann so aus:


    Ein allfällig geöffnetes OSD wird beim Umschalten geschlossen, so dass das Ausgabedevice seine Ressourcen sauber aufräumen kann. Da gibt es beim rpihddevice scheinbar noch ein Problem, nach mehrmaligem Umschalten bei geöffnetem Menu bleibt dieses pltözlich stehen und wird nicht sauber abgebaut - wo es genau klemmt, kann ich momentan leider nicht sagen, aber ich arbeite daran...


    Gruss
    Thomas

  • Ich glaube, ich würde es schöner finden, wenn die Felder z.B. durch : getrennt werden, so wie alles mögliche beim vdr.
    Dann kann man das leichter auftrennen.


    Lars.

  • Das sieht mit IPv6-Adressen dann aber lustig aus (falls die Unterstützung dafür mal eingebaut wird)

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Alles nach dem dritten Doppelpunkt ist der Devicename.
    Wenn man sich Timer von epgsearch ansieht, ist es auch lustig. :)


    Lars

  • Alternativ ließe sich natürlich auch LSTD ein Parameter mitgeben, der dann als Trennzeichen benutzt wird, aber das geht vielleicht zu weit...


    Lars

  • Genügt nicht ein Command?


    Ohne Paramter Anzeige,


    Mit Paramter Umschalten.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Es werden ja nicht nur mögliche primäre Devices angezeigt, sondern alle (vermute ich, hab noch nich in den Code geschaut). Und sowas würde ich bei PRIM ohne Parameter verwirrend finden.


    Ist ja nicht so, dass wir sparen müssen.


    Lars

  • Muß ja nicht PRIM heissen, ich fänd das übersichtlicher.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Ein Kommando, was je nach Aufruf unterschiedliche Dinge tut, findest du übersichtlicher, als zwei Kommandos? Hm, da scheinen wir einfach unterschiedlicher Meinung zu sein.


    Ist in Ordnung.


    Lars

  • Ich hab mal ähnliche Befehle in dbus2vdr v28 eingebaut (yavdr-Pakete bauen gerade). Dann kann man es auch mit ungepatchten vdr-Paketen benutzen.


    Code
    1. vdr-dbus-send.sh /Devices device.List



    Code
    1. vdr-dbus-send.sh /Devices device.GetPrimary



    Code
    1. vdr-dbus-send.sh /Devices device.RequestPrimary int32:index


    GetPrimary liefer ein struct aus zwei Integer, zwei boolean und einem String (device index, device number, hasDecoder, isPrimary, name), List das gleiche bloß als Array.
    Den device index benutzt man dann mit RequestPrimary.


    Dabei fällt auf, dass softhddevice noch keinen Namen zurück gibt, ist ja aber nur eine Kleinigkeit.


    Wenn das OSD offen ist, stürzt es nicht ab (hab aber auch keinen skindesigner laufen), aber wenn man z.B. mit offenem Menü zu dummydevice und wieder zurück zu softhddevice wechselt, dann sieht man nur die Reste des OSD, die nach dem Wechsel aktualisiert wurden. Das ist wohl das gleiche Phänomen, als wenn man softhddevice detached startet und dann kurz nach dem Start attached. Dann sieht man ja nur ein paar Reste der Kanalinfo.


    Lars.

  • Hi Lars

    Wenn das OSD offen ist, stürzt es nicht ab (hab aber auch keinen skindesigner laufen), aber wenn man z.B. mit offenem Menü zu dummydevice und wieder zurück zu softhddevice wechselt, dann sieht man nur die Reste des OSD, die nach dem Wechsel aktualisiert wurden. Das ist wohl das gleiche Phänomen, als wenn man softhddevice detached startet und dann kurz nach dem Start attached. Dann sieht man ja nur ein paar Reste der Kanalinfo.

    Liegt das nicht einfach daran, dass ein offenes Menü nicht geschlossen wird? Das ist meiner Meinung nach nur direkt innerhalb des Main-loops möglich.


    Gruss
    Thomas

  • Ja, das DELETE_MENU kann ich aus dem Plugin heraus nicht aufrufen. Aber warum das OSD schließen? Es wäre doch schöner, wenn man das offene OSD auf die andere Ausgabe verschieben könnte.


    Der vdr müsste intern (wie auch immer) das OSD cachen und bei einem Wechsel des Ausgabedevices es einmal neu zeichnen lassen. Ich weiß nicht, wie viel Aufwand das ist, ich hab mir diese Stellen im vdr bisher noch nicht intensiv angesehen.


    Lars

  • Thomas
    Hast du upstream eigentlich schon Patches für DeviceName bei dummydevice und softhddevice eingereicht?
    Ich schätze mal, dass die die beiden Plugins gepatched hast.


    Lars.

  • Bei mir kommen keine Namen von die plugins, wird wahrscheinlich mit letzten post von Lars zusammenhänge und zwar, dass dummydevice und rpihddevice patches benötigen?


    Anbei log (prim 3 ist bie mit rpihddevice, und default war vermutlich dummydevice da ich keine Bild gehabt habe):

  • dummydevice:


    softhddevice:


    rpihddevice hab ich hier nicht, aber das ist analog zu lösen.


    Lars.

  • Hi Lars


    Der vdr müsste intern (wie auch immer) das OSD cachen und bei einem Wechsel des Ausgabedevices es einmal neu zeichnen lassen.

    Das stelle ich mir bei einem High-Level-OSD recht aufwändig vor - eigentlich müsste dazu VDR alle Zeichenbefehle speichern und beim "Restore" aufs neue OSD anwenden. Anders dürfte das kaum machbar sein, da das API keinerlei Vorgaben zum Speichern der Inhalte macht. Aber eigentlich war das auch nicht das Ziel der Übung, es ging ja primär darum, die Ressourcen des gerade aktiven Ausgabeplugins freizugeben, um möglichst ohne Verzögern zu Kodi umschalten zu können.


    Hast du upstream eigentlich schon Patches für DeviceName bei dummydevice und softhddevice eingereicht?
    Ich schätze mal, dass die die beiden Plugins gepatched hast.

    Nein habe ich nicht - die Änderungen sind ja so trivial, dass ich nicht extra einen Patch dafür gemacht habe. Beim rpihddevice habe ich das am Freitag eingecheckt.


    Gruss
    Thomas

  • Wenn ich mal Zeit habe, schaue ich mir das mit dem OSD mal an, aber so sehr stört mich das auch nicht.
    Und wenn der Patch im nächsten vdr drin ist, wird das OSD ja vorher geschlossen.


    Lars

  • Danke, jetzt habe ich richtige namen.


    Kann man feststellen welche Ausgabe Plugin Standard eingestellt ist? Die rpihddevice --disable-osd ist bei mir nicht eingetragen wird aber beim VDR start auf dummydevice geschaltet.

  • "svdrpsend prim" liefert dir das aktuelle Ausgabegerät. In der setup.conf steht das Default-Gerät. Wenn man allerdings die Ladereihenfolge ändert, würden die Plugins eine andere Nummer bekommen. Deshalb sollte man da aufpassen und ggf. das dummydevice nach hinten stellen bzw. einfach dafür sorgen, dass sich die Reihenfolge nicht ändern kann.


    Lars