Menüstruktur des vdr in einem Plugin abfragen (Ergebnis: das Plugin dbus2vdr - vdr zusätzlich per dbus steuern)

mini73 · April 27, 2011 at 10:50 PM

Moin!

Ok, CallPlugin ist in Version 0.0.2f eingebaut. Deine Variante hat den Schwachpunkt, dass es auch gerne mal crashen könnte, da sich der vdr den übergebenen Pointer an cRemote::CallPlugin merkt und erst später benutzt.
Deshalb der Kommentar in vdr/remote.h, dass der Parameter "static" sein muss.

Ich hab das so gelöst, dass ich das Plugin heraussuche und dann den Pointer übergebe, der im Plugin den Namen des Plugins speichert. Ist ja der selbe Inhalt.

Code

vdr-dbus-send.sh /Remote remote.CallPlugin string:'name-of-plugin'

Lars.

posde · May 17, 2011 at 10:03 AM

Moin nach Flensburg aus Dithmarschen,

was hältst du von der Bereitstellung des aktuellen Statuses des VDRs via dbus? So ähnlich wie SVDRP CHAN den aktuellen Kanal wieder gibt, das gleiche für Recordings zu implementieren. Damit man über DBUS erfahren kann, ob und welches Recording gerade gespielt wird, wie der aktuelle Timecode ist.

Macht das Sinn für Dich?

Liebe Grüße von der tieferen Westküste.

Olly

mini73 · May 17, 2011 at 10:01 PM

Moin,

Ja, das macht Sinn. Da ich mich gerade mitten in einem Umzug befinde, kann es mit der Umsetzung aber noch ein Weilchen dauern.
Geplant ist letztlich, alles gewünschte nach und nach einzubauen, so dass irgendwann halbwegs der Funktionsumfang von SVDRP erreicht ist - plus ein paar Zusätze, die noch nicht per SVDRP möglich sind.

Also sameln und am besten als Ticket auf github erfassen, damit es nicht verloren geht...
Lars.

gda · May 17, 2011 at 10:25 PM

Quote from mini73

Ja, das macht Sinn. Da ich mich gerade mitten in einem Umzug befinde, kann es mit der Umsetzung aber noch ein Weilchen dauern.

Vielleicht auch einen Augenblick länger. Wir brauchen den Lars etwas dringender :D.

Gerald

posde · May 18, 2011 at 8:53 AM

Es liegt mir fern, irgendjemand von wichtigeren Dingen wegen meiner Kleinigkeiten abzuziehen

mini73 · May 18, 2011 at 9:12 AM

Moin!

Alles wird gut...
Freitag zieht schon mal mein DSL-Anschluss um, am Samstag ziehen wir dann hinterher. Ich hoffe mal, es klappt alles...

Lars.

Keine_Ahnung · June 8, 2011 at 3:07 PM

Habe gerade die aktuelle Version ausgecheckt, die geht unter dem 1.6er VDR nicht, denn cEitFilter::SetDisableUntil gibt es dort nicht, diese beiden Zeilen in epg.c auskommentiert dann geht das. Das per
--
#if VDRVERSNUM < XXX
...
#endif
--
umschliesen sollte reichen. Ich teste das dann natürlich gene.

BTW: Wäre es möglich einzubauen das auch EPG Einträge ausgelesen werden können, und auch einzelne EPG Einträge ohne den Umweg über eine Datei in den VDR zu importieren wäre toll?

cu

mini73 · June 8, 2011 at 9:23 PM

Moin!

Es ist alles möglich, was die Zeit erlaubt.

Größtenteils muss ich meist den Code aus svdrp.c in eine passende Funktion im Plugin kopieren (mit ein bisschen drumrum). Manche sind leichter, manche umfangreicher einzubauen.
Ich hab auf github mal ein paar Tickets dazu eingetragen, damit ich es nicht vergesse...

Einfach den passenden RSS-Feed abonnieren, dann kriegst du bescheid, wenn ich's eingebaut habe.

Lars.

Keine_Ahnung · September 9, 2011 at 12:46 PM

Ich bin gerade auf ein kleines Problem gestossen.

Die dbus Pathnamen (die hier auch die Pluginnamen enthalten) erlauben nur [A-Z][a-z][0-9][_], der VDR sagt zu den Pluginnamen es /sollte/ [a-z][0-9] verwendet werden, aber niemand zwingt die Plugins sich daran zu halten. Zumindest das "-" im Namen ist nicht so unüblich.

Allgm. üblich bei dbus scheint zu sein unerlaubte Zeichen mittels "_" zu escapen (_<2 Digit Hex>).

Ist jetzt nicht so dramatsch, aber IMHO wäre es schön diese Sache im Readme zu erwähnen oder das Escapen zu unterstützen.

cu

mini73 · September 9, 2011 at 8:10 PM

Moin!

Danke, ich hab's mal auf meine Liste geschrieben und werde es demnächst mal untersuchen. Welche Plugins haben denn ein Minus im Namen?

Lars.

Keine_Ahnung · September 9, 2011 at 8:46 PM

Quote from mini73

Danke, ich hab's mal auf meine Liste geschrieben und werde es demnächst mal untersuchen. Welche Plugins haben denn ein Minus im Namen?

Keines (gut, streamdev-client|server, aber die haben keine svdrp|service Schnittstelle), deswegen auch "kleines Problem" und alternativ (zum Escapen) die Idee das es auch reichen würde das im Readme zu erwähen.

Ich habe an meinen VDR aktuell zwei Displays, deswegen habe ich das graphlcd plugin dupliziert und unter dem Namen graphlcd-sdc und graphlcd-pearl (die Namenswahl ergibt sich hier natürlich rein intuitiv) installiert, da bin ich dann natürlich prompt auf das Problem gestossen, und da ich nicht wusste wo denn nun eigentlich das Problem liegt (habe da an dieser Stelle eigentlich keine Probleme erwartet) habe ich erstmal einige Zeit mit Google und RTFS verbracht, und damit der nächste der darauf stöst es einfacher hat halt dieses Posting um auf das Problem hinzuweisen.

cu

mini73 · September 9, 2011 at 9:02 PM

Moin!

Ach so, ich werde es dann mal im README erwähnen, sobald ich das genau verstanden hab. Bis gerade eben wusste ich ja auch noch nicht von diesem "Problem".

Danke!
Lars.

Keine_Ahnung · September 12, 2011 at 2:58 PM

Eine Sache ist mit gestern noch zufällig aufgefallen, startet man dbus neu (" invoke-rc.d dbus restart") dann restartet der VDR auch (Exitcode 1, keine GUI Abfrage und nix im Log *) ). Ist das Systembedingt so oder ist das ein Bug?

cu

*) Normalbetrieb, dann die "max. latency time X second" Meldung aus der VDR Exitfunktion und dann wars das.

mini73 · September 12, 2011 at 4:51 PM

Moin!

Es kann sein, dass das durch die Abhängigkeit und der dbus-Konfigurationsdatei de.tvdr.vdr.conf passiert.
Hab ich mir notiert - sobald mal wieder ein Abend Zeit für den vdr ist, schau ich's mir an.

Danke!
Lars.

mini73 · September 13, 2011 at 11:36 AM

Moin!

Ich hab mir das mal mit dem Escapen angesehen. Ich hab das Gefühl, dass es ein Problem von dbus-send ist, da bei meinem Plugin nichts ankommt, wenn ich einen Pfad mit einem Minuszeichen benutze. Auch ein manuelles Escapen der Parameter von dbus-send scheint keine Abhilfe zu bringen.
Ich hab mir auch mal den Source von dbus-send angesehen, da wird der Parameter einfach direkt an "dbus_message_new_method_call" verfüttert, keine Ahnung, ob da ein "dbus_address_escape_value" drumherum helfen würde, hab jetzt leider keine Zeit mehr zum Testen.
Falls du zufällig dazu kommst, wäre ich über eine Rückmeldung froh, ansonsten werde ich's die Tage mal probieren.

Lars.

mini73 · September 13, 2011 at 11:55 AM

Nachtrag:
Das Escapen von DBus-Adressen scheint sich wirklich nur auf "Server Addresses" zu beziehen, aber nicht auf "object paths". Jedenfalls verstehe ich die Doku so (und die Modifikation in dbus-send hat auch nichts gebracht, die Neugier hat dann doch gesiegt...):
http://dbus.freedesktop.org/doc/dbus-speci….html#addresses
http://dbus.freedesktop.org/doc/dbus-speci…ocol-marshaling

Deshalb müsstest du wohl das Minuszeichen mit einem Unterstrich ersetzen. Denk einfach an die Beschränkungen von Variablennamen in C/C++.

Ich denke noch über eine passende Formulierung im README nach...

Lars.

Keine_Ahnung · September 13, 2011 at 1:02 PM

Nun, so wie ich das Verstand ist ein dbus seitiges Escapen gar nicht vorgesehen (in der API oder in den Helper Funktionen). D.h. der übliche Weg wäre für ein Plugin Namens epg-search (um mal ein Beispiel zu konstruieren) folgendes zu schreiben
--
/usr/bin/dbus-send --system --type=method_call --dest=de.tvdr.vdr /Plugins/epg_2dsearch de.tvdr.vdr.plugin.SVDRPCommand string:'MENU' string:'PRG'
--
und das dbus2vdr Plugin macht dann in plugin.c
--
void cDBusMessagePlugin::Service(void)
{
const char *pluginName = unescape(dbus_message_get_path(_msg));
const char *id = NULL;
const char *data = NULL;
--
wobei unescape() jede Zeichenfolge in Form von "_xx" wieder in das ASCII Zeichen umsetzt.

Das ist meiner google Erkenntnis nach das was alle in so einem Fall tun.

Oder halt ins Readme schreiben das nur Zeichen [A-Za-z0-9_] erlaubt sind.

cu

mini73 · January 7, 2012 at 4:39 PM

Moin!

Quote from Keine_Ahnung

und auch einzelne EPG Einträge ohne den Umweg über eine Datei in den VDR zu importieren wäre toll

Ist jetzt in 0.0.3d eingebaut:

Code

vdr-dbus-send.sh /EPG epg.PutEntry string:'erste Zeile' string:'zweite Zeile' string:'dritte Zeile' (usw.)

Wenn als letztes kein '.' angegeben wird, wird der automatisch hinzugefügt.
Es kann sein, dass die introspect-Daten noch nicht richtig sind, ich muss erst mal rausfinden, wie die sein müssen, wenn ich eine variable Anzahl von Parametern erwarte.

Außerdem hab ich mich dazu entschlossen, kein Escaping einzubauen. Ist jetzt auch im README eingetragen. Da es ja eigentlich nur um Pluginnamen geht und die eigentlich auch nur Buchstaben, Zahlen und Unterstrich haben dürfen, will ich keinen verführen, gegen die Spezifikation zu verstoßen.

LSTE ist etwas aufwendiger, das kommt später irgendwann...

Lars.

mini73 · January 25, 2012 at 10:44 PM

Moin!

Quote from Keine_Ahnung

Eine Sache ist mit gestern noch zufällig aufgefallen, startet man dbus neu (" invoke-rc.d dbus restart") dann restartet der VDR auch (Exitcode 1, keine GUI Abfrage und nix im Log *) ). Ist das Systembedingt so oder ist das ein Bug?
*) Normalbetrieb, dann die "max. latency time X second" Meldung aus der VDR Exitfunktion und dann wars das.

Hm, konnte ich hier nicht nachvollziehen. Wenn ich einfach einen vdr mit dbus2vdr und dummydevice von der Kommandozeile laufen lasse, passiert nichts weiter im vdr.
Wenn ich allerdings bei einer yaVDR-Installation dbus neu starte, dann passiert da schon was. Hängt vermutlich mit den (upstart-)Abhängigkeiten zwischen vdr, openbox, vdr-frontend usw. zusammen.
Keine Ahnung...

Lars.

geronimo · February 11, 2012 at 10:45 AM

Hi,

gerade erst diesen Fred entdeckt - liest sich ja hochspannend

Schade dass Du den Gedanken mit dem Menü zu den Akten gelegt hast.
Ich denke, da würden sich einige freuen, wenn es die Möglichkeit gäbe, außerhalb des VDRs das Menü auszulesen, bzw. zu bearbeiten, ohne dass der VDR das OSD zeigt.
Den Gedanken weiter gesponnen - was hältst Du davon, die Menü-Erstellung von der Anzeige zu trennen und quasi einen Zustandsautomaten zu erstellen, der auf Anforderung das OSD anzeigt, bzw. das Menü über dbus ausgibt.
Ich denke mal, die heutigen VDR-Maschinen haben reichlich Speicher, sodass man durchaus ein paar Menüseiten im Speicher halten könnte ...
... das ganze dann noch per DBus erreichbar, vielleicht sogar per restful-Plugin für die Außenwelt zugänglich ... wäre schon genial.

Gruß Gero

Participate now!