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

Moin!

Die internen vdr-Strukturen zum Thema Menü/OSD/Skin sind da leider nicht so einfach aufzutrennen.
Dazu kommt dann noch das "Problem", dass Plugins eigene Menücontrols erstellen können, die per Zeichenbefehle des OSD gemalt werden. Da kann mein Plugin also noch nicht mal ernsthaft erraten, was da passiert.

Was ich mir vorstellen kann, ist ähnlich zum Plugin osdserver eine Schnittstelle zu einem selbsterstellten Menü zu bieten, das über das OSD angezeigt wird. Damit wäre es dann für "äußere" Programme und Scripte möglich, dem Benutzer über das OSD eine Oberfläche anzubieten - inklusive der Standardeingabefelder, die der vdr bietet (Zahlen-, Texteingabe usw.).

Um das Menü nach außen zu tragen, um es z.B. woanders als innerhalb des vdr darzustellen, muss eigentlich ein OSD-Provider geschrieben werden. Und der bietet eigentlich nur eine gewisse Anzahl von Direktiven wie "zeichne Linie von hier nach da", "schreibe Text dorthin" usw., die durch das Skin genutzt werden. Aber es weiß dann eigentlich nichts mehr über die logische Struktur des Menüs.

So ist zumindest mein Verständnis dieser Klassen. Ernshaft dokumentiert, wie die alle intern zusammenhängen, sind die leider nicht. Ich hab mich halt nur etwas an den verschiedenen Codepfaden entlang gehangelt.
Falls jemand da Wissenswertes hat, nehme ich gerne etwas Nachhilfe.

Deshalb werde ich eher den anderen Weg gehen und die internen Objekte des vdr so nach und nach über dbus zur Verfügung stellen (wie restfulapi), so dass dann ein externes Programm ein eigenes Menü (dann aber nur mit den Plugins, die es kennt) anbieten kann.
Die Daten dafür (um z.B. ein eigenes Aufnahmenmenü anzeigen zu können) kann es sich dann per dbus holen.

Lars.

Moin!

Zitat von geronimo

Hm, also meiner Ansicht nach wäre das zu weit "low-level".
Früher unter DOS hat man Menüs meist in den Bildspeicher geschrieben und dann die Seite umgeschaltet. Damit geht dann zwar Grafik, aber jeder Bezug zu logischen Strukturen ist verloren. Ok, das war vor Deiner Zeit - egal.

Naja, meine ersten Programme hab ich auf einem ZX Spectrum und C64 geschrieben. Ich fühle mich zwar noch nicht alt, hab aber dann doch schon >20 Jahre Programmiererfahrung (oh Schreck, schon so lange...?).

Zitat von geronimo

Wenn ich jetzt von einem Großteil der Menüseiten ausgehe, dann ist die Seite aufgeteilt in n Spalten und m Zeilen.
Dann gibt es noch die Information, ob eine Zeile auswählbar ist und welche Zeile die aktuelle ist.
Daraus müsste sich doch eine "portable" Menüstruktur erstellen lassen, die auch z.B. per JSon o.ä. übertragbar wäre.
Gut, manche Plugins wie "burn" oder "femon" könnten damit noch nicht dargestellt werden.

Plugins können neue von cOsdItem abgeleitete Klassen erstellen, die sich selbst darum kümmern, wie sie gemalt und bedient werden. Von denen können die anderen Plugins wie dbus2vdr effektiv nichts wissen.
Diese könnte ich also gar nicht in irgend einer Struktur nach außen geben.

Zitat von geronimo

Ein Plugin würde dann nicht mehr aktiv zeichnen, sondern lediglich die Datenstruktur bereitstellen. Für Plugins ala Recording-Menü und/oder DVD-Switch müsste dann noch eine Hierarchie unterstützt werden. Aber ich denke, das wäre mit rel. einfachem API möglich.
Damit würde sicher einiges flexibler werden und jeder OSD-Provider könnte selbst entscheiden, wo er wann wie optimiert.

Hierarchie ist schon "drin", dazu muss dann nur cOsdMenu als Basis benutzt werden.

Ausgangspunkt ist cMenuMain, das erstellt dann einige cOsdItems für die Standardpunkt wie Kanäle, Programm, Timer, Aufnahmen usw. und in Abhängigkeit von den gedrückten Tasten wird dann in den jeweiligen ProcessKey-Methoden "irgend etwas" mit dem Menü gemacht.
Es wird an ein cSkinDisplayMenu-Objekt übergeben (abgeleitet von cSkinDisplay). Und das benutzt dann irgendwie einen OSD-Provider, der dann z.B. Rechtecke malen kann usw..

Die Menüpunkte von cMenuMain lassen sich als Liste abfragen, ich bekomme dann aber simple cOsdItems. Das kann dann z.B. ein cMenuEditStrItem (also eine Texteingabe) sein, aber letztendlich kann ich nur bekannte Typen testen (via dynamic_cast).
Wenn sich ein Plugin ein neues Control ausdenkt, weiß ich nichts davon, es sei denn, ich benutze alle Header-Files usw. aller Plugins...

Ich kann dann auch einen bestimmten Menüpunkt selektieren und ihn per "Ok" auslösen. Aber spätestens dann hab ich keine Chance mehr, irgendwie auf die Menüdaten zuzugreifen.
Aber ich kann auch noch irgendwas übersehen haben...

Schau dir einfach mal osdbase.[ch], menu.[ch], menuitems[ch], osd.[ch] und skins.[ch] an.
Und dann in vdr.c die Schleife, die die Tasten an das passende Menü weitergeben.
Es ist alles gut miteinander verzahnt und nie dafür gedacht, anders ausgewertet zu werden. Im Prinzip müsste man die alle irgendwie "enttüdeln" und mit dem neuen Ziel neu zusammensetzen (und dann alle Plugins anpassen...).
Das ist mit momentan "zu viel".

Lars.

Moin!

Zitat von geronimo

Hey, wollte Dir nicht auf die Füße treten! Ich schätze Dich sehr, sonst hätte ich überhaupt nicht in Deinem Fred geschrieben.
Sollte einfach ein Augenzwinkern über Dein (geringes) Alter sein.

Keine Sorge, ich lese hier eigentlich alles mit einem Augenzwinkern, so leicht lasse ich mir nicht auf die Füße treten.
Zusätzlich versuche ich jede Art von Input zu verwerten. Es gibt viele Leute, die tolle Ideen haben, die muss ich nicht alle selbst entwickeln.

Zitat von geronimo

Für den Fall, dass Dir das CNF nicht bekannt ist, skizzier ich es mal kurz:
...

Im vdr ist es ja fast so schon drin, nur dass es keine zentrale Stelle gibt für die Controls. Z.B. bietet pvrinput eine Möglichkeit an, um die verschiedenen Einstellungen des video-Devices zu ändern wie Helligkeit, Kontrast usw.
Dafür zeichnet es beim Verstellen einen Balken ins OSD, damit man sieht, wie die Einstellung ist (wie beim Fernseher).
Da der vdr selbst so ein Control nicht hat, kümmert sich das Plugin selbst um die Darstellung. Wie sowas im CNF geregelt ist, weiß ich nicht.
Es gibt eine Menge Standard-Controls, aber eben nicht genug für alle, weil jedes Plugin sich da selbst etwas ausdenken können muss.

Aber egal, ich werde da auch nicht so schnell aufgeben. Irgendwie finde ich schon noch eine Möglichkeit.

Lars.

Moin!

Zitat von gda

Das OSD komplett aus dem VDR lösen ;), Es gehen erstmal die Plugins nicht mehr? Kollateralschaden, duck und wech.

Ja, auf so einem ähnlichen Weg bin ich gerade.

Und es kann sein, dass viele Plugins vermutlich doch einfach gehen, weil sie nichts besonderes benutzen - hoffentlich...

Lars.

Moin!

dbus2vdr 0.0.3k hat nun folgende Befehle dazu bekommen:

vdr-dbus-send /EPG epg.DisableScanner int32:3600
vdr-dbus-send /EPG epg.EnableScanner

Der Timeout ist in Sekunden und standardmäßig auf 3600, d.h. eine Stunde. Ein Deaktivieren des Scanners ohne Timeout ist ohne Eingriff in den vdr nicht möglich und eigentlich auch unpraktisch. Es könnte ja sein, dass das externe Programm irgendwie abstürzt und nicht mehr dazu kommt, den Scanner wieder zu aktivieren...

Es wird mindestens vdr 1.7.11 benötigt, vorher gab's diesen Inaktivitätstimeout nicht.

Damit lässt sich nun der EPG-Scanner abschalten, in Ruhe das EPG importieren (DisableScanner kann mehrmals nacheinander aufgerufen werden, der letzte Timeout zählt) und dann der Scanner wieder einschalten.

Danke an C-3PO für die Anregung.

Lars.

Moin!

dbus2vdr 0.0.4d hat nun im EPG-Interface "Now", "Next" und "At", damit ist der LSTE-Befehl abgedeckt.

Lars.

Moin!

Und ich danke, dass es Leute gibt, die das Plugin nutzen und ich nicht nur für die Theorie programmiere.

Lars.

Moin!

Interessante Neuerungen in Version 0.0.6c:
Es gibt einen neuen Parameter "--upstart". Der sorgt für eine bessere Integration in den Upstart-Systemstart.

Folgendes passiert:
Wenn die Initialisierungsphase der Plugins überstanden ist und der vdr das erste mal den MainThreadHook des Plugins aufruft, sendet dbus2vdr ein SIGSTOP.
Im zugehörigen Upstart-Job des vdr muss dann ein "expect stop" stehen. Upstart wartet dann auf dieses STOP-Signal und schickt sofort ein SIGCONT. Dadurch weiß Upstart, dass die Initialisierung des vdr abgeschlossen ist und abhängige Jobs endlich gestartet werden können.
Siehe dazu: http://upstart.ubuntu.com/cookbook/#expect-stop

Anschließend wird dann noch ein "initctl emit --no-wait vdr-plugin dbus2vdr=started plugin2=started plugin3=started ..." abgesetzt (wozu der vdr-User aber für Upstart-User-Jobs freigeschaltet werden muss, siehe http://upstart.ubuntu.com/cookbook/#user-job; dafür langt eine conf-Datei in /etc/dbus-1/system.d), so dass man andere Jobs davon abhängig machen kann, ob bestimmte Plugins geladen sind ("start on vdr-plugin xineliboutput=started").
Zu diesem Zeitpunkt sind sie dann auch schon vollständig initialisiert.
Wird der vdr beendet, kommt dann das gleiche Upstart-Signal bloß mit dem Parameterwert "stopped".

Ich hoffe, damit können wieder ein paar sleep-loops dahin wandern, wo sie hingehören: /dev/null

Falls jemand weiß, ob es ähnliche Mechanismen für systemd oder andere Init-Systeme gibt, würde ich gerne davon hören.

Anderes nettes Feature: dbus-activation (ging auch schon vorher)
service-Datei unter /usr/share/dbus-1/system-services anlegen mit dem Inhalt:

[D-BUS Service]
Name=de.tvdr.vdr
# wenn Upstart dann
Exec=/bin/true
UpstartJob=true
#ansonsten
Exce=und hier eintragen, wie der vdr gestartet wird

Sobald das erste Programm über dbus mit dem Plugin kommunizieren will, der vdr aber noch nicht läuft, dann wird er gestartet.
Mit Upstart kann man dann auf das Event "dbus-activation de.tvdr.vdr" reagieren und den vdr starten.

Lars.

Moin!

Zitat von Keine_Ahnung

Was mir schon länger im Hinterkopf rumgeht wäre ein simples "ping" (halt pollen aber mit der selben Idee wie die upstart Sache). Erstmal um zu erfahren ob dbus2vdr überhaupt vorhanden ist

dbus-send --system --dest=org.freedesktop.DBus --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames

liefert dir alle aktiven DBus-Busse, wenn da "de.tvdr.vdr" dabei ist, läuft das Plugin.

Zitat von Keine_Ahnung

ferner um rauszufinden ob der VDR "läuft" (d.h. NICHT gerade startet oder runterfährt)

Es gibt in dbus2vdr auch noch das Shutdown-Interface, das prüft, ob der vdr gerade herunterfahren darf, sagt aber nichts darüber aus, ob er gerade startet.

Bis ein Plugin soweit ist, dass es gestartet ist, vergeht ja ein bisschen Zeit. In einem Script wird es immer eine mögliche race condition geben zwischen "Abfrage ob" und "abhängig davon eine Aktion auslösen".
Da müsste man wohl eine Form von Lock bauen, z.B. über eine Datei. Bevor der vdr startet, wird eine lock-Datei angelegt und sobald der Start durch ist, wird sie wieder entfernt.
Abhängige Scripte müssten dann diese Datei abfragen bzw. sie selbst locken (damit der vdr nicht zwischendurch startet) und ihre Aktion durchführen.

Prinzipiell könnte ich aber mal sehen, ob ich irgendwie eine Status-Abfrage untergebracht bekomme. Mal sehen, was der vdr mir da so bietet.
Und ich könnte natürlich parallel zu den Upstart-Signalen ein allgemeines "dbus2vdr started/stopped" DBus-Signal senden. Aber dann muss auch ein Programm darauf lauschen und reagieren...

Was das Aufnahmeverzeichnis betrifft: Da muss man sich eher an die Stelle einhängen, die das Mounten ausführt, da gibt's bestimmt Hooks. Ansonsten wäre da evtl. avahi mit dem DBus-Interface org.freedesktop.Avahi.ServiceBrowser und dem Signal ItemNew interessant.

Lars.

Moin!

Zitat von Keine_Ahnung

Wobei, so wie ich das sehe lässt das die Scripte wirklich durchlaufen. Das gibt Probleme wenn Scripte tatsächlich Aktionen auslösen (z.B. bei mir die Displays ausschalten) die nicht gewünscht werden wenn der VDR dann einfach weiterläuft.

Das sollte ja auch nur aufgerufen werden, wenn man vorhat, den Rechner herunterzufahren. War ursprünglich mal für einen Aufruf aus XBMC o.ä. gedacht.
Es wird aber abgebrochen, sobald ein Script einen Exitcode ungleich Null hat. Dein Display-Script sollte ganz am Ende stehen, wenn klar ist, dass heruntergefahren wird.
Aber ein zusätzlicher Parameter wäre trotzdem nicht schlecht.

Lars.

Moin!

Mit dbus2vdr 0.0.6d bin ich mal das Problem vernünftig angegangen, wenn dbus einfach mal stoppt.
Das Plugin bekommt den Disconnect nun mit und versucht dann einfach einen Reconnect einmal pro Sekunde. Nicht jeder Versuch wird aber geloggt, sonst wird's ja zu viel.
Sobald dbus dann wieder da ist, kann's dann weitergehen.

Lars.

Moin!

Neues in dbus2vdr v0.0.6g:

vdr-dbus-send.sh /Setup setup.Get string:'key'
vdr-dbus-send.sh /Setup setup.Set string:'key' string:'value'
vdr-dbus-send.sh /Setup setup.Set string:'key' int32:value
vdr-dbus-send.sh /Setup setup.Del string:'key'

Es wird nicht jede Einstellung des vdr unterstützt, welche unterstützt werden, findet man raus mit:

vdr-dbus-send.sh /Setup setup.List

Da kann man auch sehen, ob's ein String- oder Integer-Wert ist. Dann wird die maximal zulässige Stringlänge bzw. Min/Max-Werte mit zurückgegeben.

Geht auch mit Plugin-Einstellungen, muss aber nicht immer klappen, hängt vom Plugin ab:

vdr-dbus-send.sh /Setup setup.Get string:'plugin.key'
vdr-dbus-send.sh /Setup setup.Set string:'plugin.key' string:'value'
vdr-dbus-send.sh /Setup setup.Del string:'plugin.key'

Hm, jetzt, wo ich das hier so schreibe, könnte ich eigentlich auch die Plugin-Einstellungen bei "List" ausgeben, die behandel ich sowieso anders als die vdr-core-Einstellungen...
Da wird's also vermutlich bald noch ein Update geben.

Lars.

Moin!

Neue Version: dbus2vdr 0.0.8

Ich hab den dbus-Main-Loop etwas überarbeitet (so langsam verstehe ich, was die wollen) und die Reaktionsgeschwindigkeit hat sich dadurch verbessert.
Auch funktionieren die Upstart-Signale (so man sie nutzt) nun wesentlich besser.
Der Main-Loop ist zwar noch nicht ganz so, wie es eigentlich gedacht ist, aber da das so gut wie gar nicht dokumentiert ist (man bekommt immer zu hören, "schau doch mal da oder da rein", d.h. GLib main loop integratrion, dbus-mainloop.[hc] in der libdbus o.ä.), muss ich da erst noch weiter rumprobieren.
Irgendwann wird das ganze Ding noch mal einem intensiven Refactoring unterzogen...

Im yavdr-unstable Repository ist die neue Version schon verfügbar.

Falls jemand eine höhere Last als vorher feststellt (z.B. auf Atom-Systemen o.ä.), der sollte mal mit dem Parameter "--poll-timeout" herumspielen. Standardwert ist 10 (Millisekunden), wenn die Zahl vergrößert wird, sollte die Last runtergehen, aber die Latenz für die Bearbeitung steigt dann auch entsprechend. Da muss man sich einen passenden Kompromiss aus Last und Geschwindigkeit aussuchen.
Wenn der Umbau auf die "offizielle Methode der Main-Loop-Integration" vollzogen ist, sollte dieser Parameter dann wieder überflüssig sein.
Wenn sich jemand mit DBusWatch und DBusTimeout und den ganzen Geraffel um den Mainloop auskennt, würde ich mich über entsprechende Tipps freuen. Heute abend werde ich erst mal die dbus-Mailingliste abonnieren (hätte ich schon längst mal tun sollen).

Lars.