You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

mini73

Moderator

  • "mini73" started this thread

Posts: 5,760

Location: Flensburg

  • Send private message

41

Saturday, February 11th 2012, 2:32pm

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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

42

Saturday, February 11th 2012, 3:52pm

Hi,

Quoted

... muss eigentlich ein OSD-Provider geschrieben werden.

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.

Ich denke, man sollte früher ansetzen.

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.

... aber vielleicht ließe sich auf einer solchen Menüstruktur dann für unterschiedliche Devices jeweils ein OSD-Provider erstellen?

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.

Eine gute Vorlage hierzu wäre das Common-Navigator-Framework von Eclipse.
Das ist auch eine einzige Hierarchie, die von Plugins erweitert werden kann, ohne dass das Plugin, welches die Inhalte liefert, wissen muss, was wann wie gezeichnet wird.
Das komplette Framework zu portieren ist sicher viel zu komplex, aber in die Richtung zu denken wäre sicher kein Fehler.

Gruß Gero

mini73

Moderator

  • "mini73" started this thread

Posts: 5,760

Location: Flensburg

  • Send private message

43

Saturday, February 11th 2012, 7:46pm

Moin!

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...?). ;-)

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.

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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

44

Sunday, February 12th 2012, 8:36am

Moin moin,

Quoted

... , hab aber dann doch schon >20 Jahre Programmiererfahrung

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.

Quoted

Das ist mit momentan "zu viel". ;-)

OK, das ist natürlich ein sehr gewichtiger Grund.

... und ich stimme Dir zu, dass so eine skizzierte Radikalkur nicht zu machen ist.
Wenn man wirklich alte Zöpfe loswerden will, dann geht das nur mit "sanfter Migration" - sprich: man macht das neue zusätzlich (Stück für Stück) - und erst wenn's zufriedenstellend funzt, werden die alten Zöpfe abgeschnitten (man könnte dem neuen Menü ja einen eigenen Hotkey verpassen).

Es gibt nicht viele Konzepte, die mich so spontan begeistert haben, wie das CNF.
Wenn man es übertragen würde - das Menü könnte man ja auch als Baumstruktur ansehen, von der jeweils nur ein kleiner Teil angezeigt wird.

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

Es gibt ein Wurzelelement (root oder hier Hauptmenü), welches im Container (z.B. OSD) angezeigt wird.
Dann gibt es einen Content-Provider, der immer wenn der Container Daten braucht, gefragt wird, ob es Kinder von dem Wurzelelement gibt.
Plugins können nun selbst Content-Provider anmelden und dabei noch angeben, bei welchem Typ von "Menüeintrag" sie gefragt werden wollen (der Sinn ist der, dass Menüeinträge von unterschiedlichem Typ sein können, um die Anzahl der zu fragenden Content-Provider gering zu halten)
Der Container, bzw. sein Controller hält die Liste der Provider mit den Abhängigkeiten.
Wird nun ein Menüpunkt aktiviert (z.B. Enter auf dem Eintrag), dann wird in der Liste der Content-Provider geschaut, ob einer für den Typ des aktivierten Menüeintrags registriert wurde. Wenn ja, wird dieser gefragt, ob der Menüeintrag Kinder hat. Wenn ja, wird nach der Liste der Kindelemente gefragt. Als Fallback dient immer der Content-Provider des Hauptmenüs.
Falls ein Menüeintrag keine Kinder hat, könnte der Content-Provider eine entsprechende Aktion auslösen.
Wenn man dann noch das Konzept des Selection-Providers dazu nimmt, könnte ein solcher Selection-Provider den aktiven Menüeintrag jeweils z.B. per DBus veröffentlichen.

Für die Datenstruktur könnte ich mir folgendes vorstellen:
Es gibt Menü-Zellen
  • Typ
  • editierbar [J/N]
  • Inhalt

und Menü-Elemente (die Zeilen)
  • Array von Menü-Zellen
  • wenn Array nicht NULL-terminiert, Anzahl der Zellen
  • Typ des Menü-Elements
  • Menü-Aktion (Funktions-Zeiger)
  • auswählbar [J/N]
  • änderbar [J/N]

dementsprechend hat dann eine Menüseite eine Liste von Tabulatoren (kann je nach Device unterschiedlich sein) und eine Anzahl von Platzhaltern, in denen Menü-Elemente angezeigt werden können. Die Tabulatoren könnte man evtl. mit dem Content-Provider abstimmen, sodass der Content-Provider seine Wunsch-Tabulatoren angibt, die der Menü-Controller aber deviceabhängig überschreiben kann.
Da bei C++-Anwendungen ja alles in Silikon gegossen wird, könnte der "Typ" textuell im Menü-Element hinterlegt werden, sodass jedes Plugin einen eigenen Menütyp haben kann. Gibt es mehrere Content-Provider zum gleichen Menütyp, werden die Menüelemente unterschiedlicher Plugins zusammen geführt (eine Liste - z.B. oberste Ebene Hauptmenü).
Zell-Editoren gehören zur Kernfunktionalität des VDRs und kein Plugin kann/soll/muss sich um das Editieren von Daten kümmern. Hier müsste man noch festlegen, wann und wie Änderungen committed werden.

Ich denke, mit einem solchen Aufbau ließe sich ein Menü sowohl für OSD, alsauch für Webseiten aufbereiten, inclusive Editiermöglichkeiten.

Gruß Gero

mini73

Moderator

  • "mini73" started this thread

Posts: 5,760

Location: Flensburg

  • Send private message

45

Sunday, February 12th 2012, 11:22am

Moin!


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.


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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

gda

Im Forum Zuhause

Posts: 13,225

Location: HH

  • Send private message

46

Sunday, February 12th 2012, 11:29am

Es gibt viele Leute, die tolle Ideen haben, die muss ich nicht alle selbst entwickeln.


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

Gerald

HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 12.04.2, Plex Media Server
Samsung UE55H6470

mini73

Moderator

  • "mini73" started this thread

Posts: 5,760

Location: Flensburg

  • Send private message

47

Sunday, February 12th 2012, 12:56pm

Moin!

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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

48

Sunday, February 12th 2012, 1:27pm

Hi,

Quoted

Im vdr ist es ja fast so schon drin

Naja - nicht wirklich. Da muss man schon alle 4 Augen zudrücken, um da ne Ähnlichkeit zu entdecken.

Weiß nicht ob es noch so ist, als ich vor längerem mal den einen oder anderen Quältext anschaute, sah ich überall den Tastaturswitch.
Ist natürlich suboptimal, wenn jeder das gleiche immer wieder schreiben muss.

Quoted

Dafür zeichnet es beim Verstellen einen Balken ins OSD, damit man sieht, wie die Einstellung

Na, zum einen wäre das bereits ein Editor und zum anderen ist ein Slider für eine Zahl beileibe nix neues mehr.
Das könnte man durchaus in ein Standard-Control packen.

Quoted

Es gibt eine Menge Standard-Controls, aber eben nicht genug für alle, weil jedes Plugin sich da selbst etwas ausdenken können muss.

Hm, genau das sehe ich komplett anders.

Das Plugin mag bestimmen, ob ein Wert eine Zahl oder Text ist und in welchen Bereichen sie geändert werden kann (Einsatz von Validatoren).
Das Control würde ich aber dem Controller überlassen, der das Menü letztlich für die Ausgabe generiert.
Warum soll sich ein Plugin darum kümmern (müssen)?

Der eine Skin-Entwickler mag einen Slider als grafischen Drehknopf implementieren, der nächste macht den Schieber im Textmodus mit senkrechten Balken.
... und der Web-Entwickler nimmt dafür ein Control von extJS oder was auch immer - und alle Controls ändern den gleichen Wert für dasselbe Plugin.
Wenn man das Plugin von der OSD-Ausgabe entkoppelt, wird plötzlich vieles leichter und portabler.

Gruß Gero

mini73

Moderator

  • "mini73" started this thread

Posts: 5,760

Location: Flensburg

  • Send private message

49

Wednesday, March 7th 2012, 8:16pm

Moin!

dbus2vdr 0.0.3k hat nun folgende Befehle dazu bekommen:

Source code

1
2
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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

mini73

Moderator

  • "mini73" started this thread

Posts: 5,760

Location: Flensburg

  • Send private message

50

Thursday, April 12th 2012, 2:09pm

Moin!

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

Lars.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

avjui

Intermediate

Posts: 394

Location: Vorarlberg

  • Send private message

51

Thursday, April 12th 2012, 9:38pm

Ich wollte hier mal an der Stelle einfach Danke sagen für deine tolle Arbeit.

:tup

Signatur

Produktiv VDR : Gehäuse Silverstone LC17 in Silber, Foxconn G31M, Core2 Duo E7300 ,2 GB Ram (800MHZ), Zotac GT240 passiv ,2,5" 160GB SATA II, TV @nywhere S2 + Technotrend C1501, Atric rev.5,
Harmony 895 freeVDR entwicklerversion (Ubuntu 14.04, vdr-2.1.1, softhddevice git Stand 24.08.2014 ,xbmc Kodi)
zum Spielen 1: Raspberry Pi 256MB diverse Systeme (Openelec, Raspbmc)
zum Spielen 2: Solid Run Cubox
Link für besseres Google Ergebnis:www.js-tischler.at

mini73

Moderator

  • "mini73" started this thread

Posts: 5,760

Location: Flensburg

  • Send private message

52

Friday, April 13th 2012, 10:21am

Moin!

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

Lars.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

mini73

Moderator

  • "mini73" started this thread

Posts: 5,760

Location: Flensburg

  • Send private message

53

Wednesday, May 9th 2012, 8:21pm

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:

Source code

1
2
3
4
5
6
7
[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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

54

Wednesday, May 9th 2012, 8:31pm

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


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, ferner um rauszufinden ob der VDR "läuft" (d.h. NICHT gerade startet oder runterfährt), das könnte das Ping ja auch in der Antwort mitliefern.

Die eine Anwendung für die ich mir das schon mal gewünscht hätte wäre z.B. die Script für den ACPI Power Button. Weil das übliche "wenn (ps | gep vdr) dann 'hitk power' ansonsten 'shutdown -h -P now'" ist sehr wackelig für den Moment in dem der VDR gerade startet oder sich beendet.

Und so was (die while Schleife mit dbus) ginge damit dann auch eleganter: [0.4] Aufnahmeliste wird beim Start nicht aktualisiert

cu

Mein VDR

Mein VDR
Digitainer2xBouget DVB-SDebian Squeeze (Kernel 2.6.35.3 von kernel.org)Softdevice Ausgabepluginvdr 1.6.0-3 (Extensions Patch 72) und viele Plugins von SourceMedion X10 FernbedienungSDC-Megtron Display (240x128x1) mit GraphLCD-PluginFreevo 1.9.0
Vodcatcher Helper in ein freundliches DEB verpackt, Tester Willkommen: http://dl.dropbox.com/s/705bh6ydgisfrqu/index.htmlFingerprint: 8A104A00D5031773A9F72A19BAEE135EA7860149

mini73

Moderator

  • "mini73" started this thread

Posts: 5,760

Location: Flensburg

  • Send private message

55

Wednesday, May 9th 2012, 9:49pm

Moin!

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

Source code

1
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.

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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

56

Wednesday, May 9th 2012, 9:59pm

Es gibt in dbus2vdr auch noch das Shutdown-Interface, das prüft, ob der vdr gerade herunterfahren darf,


Dazu auch nochmal kurz angemerkt.
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.
Evtl. wäre es sinnig hier einen 6. Parameter ("TEST") zu definieren (dbus2vdr ruft die halt mit "TEST" als 6. Parameter auf) so das die Scripte wissen das es jetzt nur eine Testanfrage ist.

[zum Rest dann später nen Kommentar]

cu

Mein VDR

Mein VDR
Digitainer2xBouget DVB-SDebian Squeeze (Kernel 2.6.35.3 von kernel.org)Softdevice Ausgabepluginvdr 1.6.0-3 (Extensions Patch 72) und viele Plugins von SourceMedion X10 FernbedienungSDC-Megtron Display (240x128x1) mit GraphLCD-PluginFreevo 1.9.0
Vodcatcher Helper in ein freundliches DEB verpackt, Tester Willkommen: http://dl.dropbox.com/s/705bh6ydgisfrqu/index.htmlFingerprint: 8A104A00D5031773A9F72A19BAEE135EA7860149

mini73

Moderator

  • "mini73" started this thread

Posts: 5,760

Location: Flensburg

  • Send private message

57

Wednesday, May 9th 2012, 10:36pm

Moin!

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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

mini73

Moderator

  • "mini73" started this thread

Posts: 5,760

Location: Flensburg

  • Send private message

58

Sunday, May 13th 2012, 4:35pm

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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

mini73

Moderator

  • "mini73" started this thread

Posts: 5,760

Location: Flensburg

  • Send private message

59

Wednesday, May 23rd 2012, 8:00pm

Moin!

Neues in dbus2vdr v0.0.6g:

Source code

1
2
3
4
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:

Source code

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

Source code

1
2
3
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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

mini73

Moderator

  • "mini73" started this thread

Posts: 5,760

Location: Flensburg

  • Send private message

60

Thursday, July 12th 2012, 10:57am

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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |