Primäres Device per SVDRP-Kommando umschalten

reufer · 12. Februar 2016

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

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

Code

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

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

Code

localhost ~ # svdrpsend lstd     
220 localhost SVDRP VideoDiskRecorder 2.3.1; Fri Feb 12 14:52:14 2016; UTF-8
250-1 [--] 192.168.3.6
250-2 [DP] rpihddevice
250 3 [D-] dummydevice
221 localhost closing connection


localhost ~ # svdrpsend prim
220 localhost SVDRP VideoDiskRecorder 2.3.1; Fri Feb 12 14:52:28 2016; UTF-8
250 2 [DP] rpihddevice
221 localhost closing connection


localhost ~ # svdrpsend prim 3
220 localhost SVDRP VideoDiskRecorder 2.3.1; Fri Feb 12 14:52:54 2016; UTF-8
250 Requested to set new primary device to 3
221 localhost closing connection


localhost ~ # svdrpsend prim
220 localhost SVDRP VideoDiskRecorder 2.3.1; Fri Feb 12 14:53:01 2016; UTF-8
250 3 [DP] dummydevice
221 localhost closing connection

Alles anzeigen

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

mini73 · 12. Februar 2016

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.

mini73 · 12. Februar 2016

Ausgabe wäre dann, z.B.

Code

250-1:::192.168.3.6
250-2:D:P:rpihddevice
250 3:D::dummydevice

Lars

seahawk1986 · 12. Februar 2016

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

mini73 · 12. Februar 2016

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

Lars

mini73 · 12. Februar 2016

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

Lars

jsffm · 12. Februar 2016

Genügt nicht ein Command?

Ohne Paramter Anzeige,

Mit Paramter Umschalten.

mini73 · 12. Februar 2016

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

jsffm · 12. Februar 2016

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

mini73 · 12. Februar 2016

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

mini73 · 13. Februar 2016

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

Code

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

Spoiler anzeigen

Code

# vdr-dbus-send /Devices device.List
method return sender=:1.94 -> dest=:1.97 reply_serial=2
   array [
      struct {
         int32 0
         int32 0
         boolean false
         boolean false
         string "DRXK DVB-C DVB-T"
      }
      struct {
         int32 1
         int32 1
         boolean false
         boolean false
         string "DRXK DVB-C DVB-T"
      }
      struct {
         int32 2
         int32 2
         boolean false
         boolean false
         string "STV0367 DVB-C DVB-T"
      }
      struct {
         int32 3
         int32 3
         boolean false
         boolean false
         string "STV0367 DVB-C DVB-T"
      }
      struct {
         int32 4
         int32 4
         boolean false
         boolean false
         string "dynamite-cDynamicDevice-4"
      }
      struct {
         int32 5
         int32 5
         boolean false
         boolean false
         string "dynamite-cDynamicDevice-5"
      }
      struct {
         int32 6
         int32 6
         boolean false
         boolean false
         string "dynamite-cDynamicDevice-6"
      }
      struct {
         int32 7
         int32 7
         boolean false
         boolean false
         string "dynamite-cDynamicDevice-7"
      }
      struct {
         int32 8
         int32 8
         boolean true
         boolean false
         string ""
      }
      struct {
         int32 9
         int32 9
         boolean true
         boolean true
         string ""
      }
      struct {
         int32 10
         int32 10
         boolean false
         boolean false
         string "dynamite-cDynamicDevice-8"
      }
      struct {
         int32 11
         int32 11
         boolean false
         boolean false
         string "dynamite-cDynamicDevice-9"
      }
      struct {
         int32 12
         int32 12
         boolean false
         boolean false
         string "dynamite-cDynamicDevice-10"
      }
      struct {
         int32 13
         int32 13
         boolean false
         boolean false
         string "dynamite-cDynamicDevice-11"
      }
      struct {
         int32 14
         int32 14
         boolean false
         boolean false
         string "dynamite-cDynamicDevice-12"
      }
   ]

Alles anzeigen

Code

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

Spoiler anzeigen

Code

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.

reufer · 14. Februar 2016

Hi Lars

Zitat von mini73

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

mini73 · 14. Februar 2016

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

mini73 · 14. Februar 2016

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.

crow · 14. Februar 2016

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):

Spoiler anzeigen

mini73 · 14. Februar 2016

dummydevice:

Diff

--- a/dummydevice.c
+++ b/dummydevice.c
@@ -52,6 +52,7 @@
     cDummyDevice() : cDevice() {}
     virtual ~cDummyDevice() {}


+    virtual cString DeviceName(void) const { return "dummydevice"; }
     virtual bool HasDecoder(void) const { return true; }


     virtual bool SetPlayMode(ePlayMode PlayMode) {return true;}

Alles anzeigen

softhddevice:

Diff

--- a/softhddevice.cpp
+++ b/softhddevice.cpp
@@ -2233,6 +2233,7 @@
     cSoftHdDevice(void);
     virtual ~ cSoftHdDevice(void);


+    virtual cString DeviceName(void) const { return "softhddevice"; }
     virtual bool HasDecoder(void) const;
     virtual bool CanReplay(void) const;
     virtual bool SetPlayMode(ePlayMode);

Alles anzeigen

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

Lars.

reufer · 14. Februar 2016

Hi Lars

Zitat von mini73

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.

Zitat von mini73

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

mini73 · 14. Februar 2016

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

crow · 14. Februar 2016

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.

Spoiler anzeigen

mini73 · 14. Februar 2016

"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

Primäres Device per SVDRP-Kommando umschalten

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema