easyVDR5: Setup-Plugin

[Wirbel]

Zum anderen Thema Setup-plugin, was hier aufgestoßen ist:
Ich denke ein plugin, das installierte plugins listet und diese aktivieren/deaktivieren kann, eventuell noch die Einstellungen der einzelnen plugins bedienen kann sollte doch eigentlich reichen.

Ps: Da ich weder vom VDR noch Plugins Entwickler/Skript Ahnung habe, bin ich hier raus und kann nur zuschauen, nichts beisteuern! Beim bashen/skripten wäre es was anderes.

Gruss Aaron

Ich denke, diese Frage wäre es wert in einen eigenen Thread ausgelagert zu werden.
Dann könnte man dieses Problem versuchen zu lösen. Jeder ein Stückchen dabei und es wird leichter.

[mango]

Hallo,

bei Plugin setup sind die Parameter der Pligins in der setup.xml hinterlegt.
Wird Plugin menuorg verwendet,fehlt der Teil zum aktivieren/deaktiviern der Plugins
und auch noch andere Punkte zur konfiguration von VDR.
Unter Debian/ubuntu/Arch auch yavdr kommt die konfiguration der Plugins nach
/etc/vdr/conf.d/*.conf z.b 00-vdr.conf
Inhalt:

Code:

#
# This file contains the arguments for VDR if invoked without arguments on the
# command line.
#
# See `man vdr`.
#

[vdr]
--record=/usr/lib/vdr/vdr-recordingaction
--user=vdr
--grab=/tmp
--port=6419
--watchdog=0
--shutdown=/usr/lib/vdr/vdr-shutdown.wrapper
--dirnames=,,1

Das heisst auch das Parameter für Plugins im Paket des Plugins in einer <name-plugin>.conf
hinterlegt sind.z.B Plugin osdteletext

Code:

#
# Command line parameters for vdr-plugin-osdteletext
#
# For more details see /usr/share/doc/vdr-plugin-osdteletext/README.gz
#
#  -d        --directory=DIR    The directory where the temporary
#                              files will be stored.
#                              (default: /var/cache/vdr/vtx)
#                              Ensure that the directory exists and is writable.
#  -n        --max-cache=NUM    Maximum size in megabytes of cache used
#                              to store the pages on the harddisk.
#                              (default: a calculated value below 50 MB)
#  -s        --cache-system=SYS Set the cache system to be used.
#                              Choose "legacy" for the traditional
#                              one-file-per-page system.
#                              Default is "packed" for the
#                              one-file-for-a-few-pages system.
#  -t,      --toptext          Store top text pages at cache. (unviewable pages
[osdteletext]
-d /run/shm/vtx
-n 48
-s packed

Info -> https://www.yavdr.org/documentation/0.6/de/ch01s06.html

Plugins werden mit vdrctl aktiviert/deaktiviert.
Siehe -> https://github.com/CReimer/vdrctl

Gruss
Wolfgang

[gb]

Hi,

Thema wurde geteilt, so haben wir nun eine klare Trennung.

Folgendes finde ich schon mal interessant und hat auch ein Minimum Ähnlichkeit mit systemctl.
So wird die Sache auch ein wenig statisch, was das abwählen/anwählen betrifft:

Hilfe zu vdrctl anzeigen.

Code:

$ vdrctl -h

Status aller verfügbaren Plugins.

Code:

$ vdrctl status

Aktivierung eines Plugins.

Code:

$ sudo vdrctl enable streamdev-client

Aktivierung eines Plugins unter Angabe der Priorität.

Code:

$ sudo vdrctl enable dynamite -p 90

Aktivierung mehrerer Plugins.

Code:

$ sudo vdrctl enable streamdev-client vnsiserver

Deaktivierung eines Plugins.

Code:

$ sudo vdrctl disable iptv

Deaktivierung mehrerer Plugins.

Code:

$ sudo vdrctl disable streamdev-client streamdev-server iptv

Gruß Aaron

[Wirbel]

Die beiden conf Dateien sind leider keine ini Dateien.
In einer ini Datei wären je Sektion Paare aus <Name> = <Wert>. Damit ist dieses System nicht erweiterbar.

Soweit ich sehe sind bis jetzt an Notwendigkeiten für vdr-2.4:
1. Installierte Plugins 'verwalten'
1.1 Übergabe von Parametern an Plugins aus nicht erweiterbaren Textdateien, d.h. /etc/vdr/conf.d/<name-plugin>.conf
1.2 Plugins aktivieren, wobei z.Z. 'de/aktivieren' per Ändern von Symlinks mit einem Perl Script erfolgt.
Der aktuelle Status aktiviert/deaktiviert wird anscheinend nicht in einer weiteren datei gespeichert, abgesehen vom gesetzten/fehlenden Symlink.
Status Änderung braucht einen Neustart des VDR Prozesses.

[gb]

Ich sehe schon, hier sollte man mal Lektüre für den reinen VDR zusammen suchen, um das jetzige Prozedere zu verstehen. 
Beispiel: vdr + Frontend + ein weiteres plugin

Ok, ignorieren wir mal kurz den menuorg plugin Teil mit vdrctl usw.

Entschuldigung, wenn hier mal ins Blaue/naiv frage..
Wie ist da der Werdegang bzw die richtige Herangehensweise?

Gruß Aaron

[Wirbel]

Dazu benötigt man weder Setup plugin, noch menuorg Plugin und auch keine Patches für den VDR.

Es sind diese beiden Plugins, welche alles komplizieren.

[gb]

Hi Wirbel

Es sind diese beiden Plugins, welche alles komplizieren.

Danke, also läuft es noch immer nach dem alten Prinzip:

Step1: Konfugation für das jeweilige Plugin, in separater conf Datei usw... ( oder ist hier schon das Problem )

Step2: Plugin mit vdr starten:
-P <plugin>

Status Änderung braucht einen Neustart des VDR Prozesses.

Ok, das ist verständlich.
Ein Problem sollte uns da bekannt sein:
Elternprozess/Kindprozess > stoppe ich mich selbst, sterben alle folgenden Prozesse zum starten.
Aber ich denke da könnte uns Systemd helfen, bzw ein VDR Daemon. Wäre zumindest auch lösbar.


Gruß Aaron

[Wirbel]

Den gesamten Punkt 1. könnte man in ein eigenes Plugin gießen, so dass man ein Plugin stoppen kann ohne den gesamten VDR jedesmal stoppen zu müssen;

Nicht alle Plugins sind sauber programmiert, also müßte man je Plugin in einer Textdatei oder Ini definieren
- soll das Plugin geladen werden beim VDR start
- darf das Plugin gestoppt werden so dass VDR weiter läuft

Nur nützt das alles nix, wenn trotzdem weitere Abhängigkeiten von diesen beiden Plugins existieren.

[gb]

Hi Wirbel

Nur nützt das alles nix, wenn trotzdem weitere Abhängigkeiten von diesen beiden Plugins existieren.

Ich hab damit kein Problem, wenn wir diese Plugins außen vor lassen, wir können das Kind ruhig beim Namen nennen menuorg/Setup-Plugin ( alt )

Da Wolfgang hier uns VDR + Plugin bereit stellt, obliegt natürlich ihm die vollständige Entscheidungsgewalt und seine Meinung ist gefragt.

Was ich noch nicht verstanden habe, ist es denn möglich dem VDR zu sagen, das Plugin gehört zu Medien, das Plugin ist Timer und das Plugin gehört zur Verwaltung. Das man zB eine ordentliche OSD Menüstruktur zusammen bekommt.

Gruß Aaron

[mango]

Hallo,

sudo vdrctl enable dynamite -p 90

die Prio der Plugins wird über vdrargs bei install übergeben.
z.B plugin dynamte
Inhalt vdrargs

Code:

debian/dynamite.conf 90

Was ich noch nicht verstanden habe, ist es denn möglich dem VDR zu sagen, das Plugin gehört zu Medien, das Plugin ist Timer und das Plugin gehört zur Verwaltung. Das man zB eine ordentliche OSD Menüstruktur zusammen bekommt.

Hier ein Screenshot easyVDR-3.5(trusty) mit VDR-2.3.8(ohne vdrargs) und Plugin menuorg

Wie man sieht haben wir damit die Möglichkeit das Menu ähnlch zu gestalten.

P.S
Im Anhang meine "menuorg.xml"

Gruss
Wolfgang

[gb]

Hallo Wolfgang 

So wirds jetzt auch nicht besser/einfacher Wir kreisen immer wieder um Plugins umher, die aktiv Patches auf den VDR einwirken lassen.

Patches:
Das Plugin benötigt einen Patch der auf den VDR angewendet werden muss. Dieser Patch ist so konzipiert, dass er die API des VDR nicht ändert. Dies bedeutet, dass ein Neukompilieren der Plugins entfällt.

Irgendwie ist das alles ganz schön verworren. 

Gruß Aaron

[mango]

Hallo Aaron,

Irgendwie ist das alles ganz schön verworren.

warum?Wird VDR für Plugin menuorg patched dann braucht man die Plugins nicht erneut zu übersetzen.
Was aber bei einem neuem VDR-2.4.x auch keine Rolle spielt,da sowieso alle Plugins
(soweit sie noch mit VDR-2..4.x funktionieren) auch neu mit vdrargs gebaut werden müssen.
Viele liebgewonnene Plugins werden aber nicht mehr dabei sein z.B Plugin music & music-sd
..damit ist dann auch easyvdr-addon-netradio obsolet!

Gruss
Wolfgang

[gb]

Hi Wolfgang

Was aber bei einem neuem VDR-2.4.x auch keine Rolle spielt,da sowieso alle Plugins
(soweit sie noch mit VDR-2..4.x funktionieren) auch neu mit vdrargs gebaut werden müssen.
Viele liebgewonnene Plugins werden aber nicht mehr dabei sein z.B Plugin music & music-sd
..damit ist dann auch easyvdr-addon-netradio obsolet!

Das ist richtig, sicher bleiben viele tolle Plugins auf der Strecke, die eigentlich ein Mehrwert für VDR haben. Aber andersrum bleibt VDR auf der Strecke, wenn allein das Frontend nicht mehr mit VDR >2.4.x will. Auch die Plugins, die stetig weiter entwickelt werden, können mit >2.4.x nix anfangen usw...

Ps: Ich fand auch die Argumentation von Wirbel zum Frontend recht erfrischend:

Was ich mich schon lange frage: kann man diese Myriaden von <softhddevice Abkömmlingen> aka {va-api, vdr-plugin-softhddevice-vpp_support_hevc, vdr-plugin-softhddevice-vdpau-vaapi-cuvid, vdr-plugin-softhddevice-FooBar} endlich mal wieder zu einem einzigen zusammenführen?

Also zu einem Plugin, was man einfach compilieren kann und das dann auch funktioniert?

Ein Plugin bei dem man nun *seit Hunderten von Jahren* bestehende Compiler Warnungen (siehe -Wall und -Wextra seit der ersten Version) und Compiler Fehler mal schrittweise entfernen/abstellen kann (egal, welchen Linux compiler man nun gerade benutzt).

Eines, welches nicht ewig die Konsole vollmüllt und bei dem durch (ja - ganz genau diese!) zeitaufwändigen Meldungen in der Konsole das Plugin dann selbst bei zeitkritischen Aufgaben außer Tritt kommt. Und in einem ewigen Rhythmus aus selbstverursachten Meldungen bis zum Restart bleibt.

Und ein Plugin, bei dem man eine (ja - ganz genau eine!) Liste von dependencies von benötigten Libs mit Mindestversionen abarbeitet

und welches danach einfach mal funktioniert. Egal was man für andre Multimedia-Libs hat - sofern sie den Anforderungen laut README entsprechen.

Mittlerweile frage ich mich, ob man dieses Plugin nicht einfach durch ein neues ersetzen muss oder das durch libvlc (und ja, das geht einfach so, VLC ist nichts als ein wrapper um diese libvlc) plus ein OSD ersetzen (und das ist die einzige Schwierigkeit) sollte.

Bei den unzähligen Frontends blickt man ja bald nicht mehr durch.
Hut ab vor den Leuten, die überhaupt noch wissen, wo welcher Patch wo hin gehört und welche Frontend für was gut ist.

Gruß Aaron

[mango]

Hi Aaron,

Ps: Ich fand auch die Argumentation von Wirbel zum Frontend recht erfrischend:

das war auch mal nötig den Finger auf die Wunde zu legen.Nicht nur die div. Versionen von SHD
sondern das auch verschiedene Versionen von ffmpeg verwendet werden.
z,B ffmpeg-2.8 damit SHD auch noch mit nvidia(alte Karten) funktioniert,um ein durcheinander
bei den lib & *.dev Paketen zu verhindern wird hier dann mit Prefix *-ffmpeg-opti-dev compiled.
und ffmpeg nach /opt installiert.
Um es Allen recht zu machen,muss man immer kompromisse eingehen
...aber der Zustand wie er sich im Moment mit SHD darstellt,ist nicht der Beste!

Gruss
Wolfgang

[Wirbel]

ok. Wieder ein Stückchen am Knoten gezogen. Jetzt also:
-----------------------
Soweit ich sehe sind bis jetzt an Notwendigkeiten für vdr-2.4:
1. Installierte Plugins 'verwalten'
1.1 Übergabe von Parametern an Plugins aus nicht erweiterbaren Textdateien, d.h. /etc/vdr/conf.d/<name-plugin>.conf
1.2 Plugins aktivieren, wobei z.Z. 'de/aktivieren' per Ändern von Symlinks mit einem Perl Script erfolgt.
Der aktuelle Status aktiviert/deaktiviert wird anscheinend nicht in einer weiteren datei gespeichert, abgesehen vom gesetzten/fehlenden Symlink.
Status Änderung braucht einen Neustart des VDR Prozesses.

2. Als Ersatz für das Setup Plugins kann 'menuorg' verwendet werden, welches
2.1 keine Plugin Verwaltung hat
2.2 noch unklar: "fehlen auch noch andere Punkte zur konfiguration von VDR."
2.3 anstelle der Datei 'setup.xml' eine Datei namens 'menuorg.xml' benutzt.
2.4 prinzipiell ähnlich wie das Setup Plugin, das VDR Menü umbaut.

Geht menuorg mit 2.4 ?

[SurfaceCleanerZ]

Hi, 
Zumindest für 2.4.0 gab es ja einen gewissen Multipatch mit menuorg 
https://www.vdr-portal.de/forum/index.ph...vdr-2-4-0/
Mfg Stefan

[mango]

Hi Wirbel,

2.2 noch unklar: "fehlen auch noch andere Punkte zur konfiguration von VDR."

Samba-Einstellungen/Freigaben können aber über das Setup-Tool getätigt werden.
Auswahl der channels.conf - kann aber auch im EasyPortal ausgewählt werden.
..muss da mal nachschauen on nicht auch Plugin setup im spiel ist.
Aktivieren WOL - geht auch über Setup-Tool/EasyPortal
Sind noch ein paar Einstellungen,muss mir dazu das Menu erstmal noch anschauen.
Was dann natürlich wegfällt,ist die Möglichkeit das Menu für sich anzupassen.
Bei Plugin menuorg muss man dann den Editor bemühen.

Geht menuorg mit 2.4 ?

Ja!

Gruss
Wolfgang

[gb]

Hi..

Samba-Einstellungen/Freigaben können aber über das Setup-Tool getätigt werden.

Ich finde Samba gehört ins easyVDR-Setup und ist unter Netzwerk ganz gut aufgehoben. Das sind Dinge, die man 1x einstellt und dann so lässt.
Gleiches wäre Auswahl Fernbedienung, das gehört auch eher ins easyVDR-Setup.
Da gibt es einige Punkte, die nicht unbedingt ein must have sind und daher für ein Setup-Plugin eher zweitrangig sind.
Wir wollen Wirbel ja nicht unbedingt die Arbeit verkomplizieren...

Was ich allerdings praktisch fand, ist zB die cannels.conf mal schnell zu wechseln, also Auswahl aus aller cannels.conf's 

Was dann natürlich wegfällt,ist die Möglichkeit das Menu für sich anzupassen.
Bei Plugin menuorg muss man dann den Editor bemühen.

Sehe ich jetzt auch nicht so dramatisch, wird fest strukturiert vorgegeben und gut ists.
Vor allem, nimmst du menuorg, sind solche praktische Sachen ja weiterhin machbar:

Code:

<command name="Kodi starten" execute="echo KODI &gt; /tmp/.pch-exec | at now " />

Gruß Aaron

[Bleifuss2]

Hi Leute

Ich sehe es so, lieber weniger und dafür funktioniert es.
Plugin Verwaltung wäre schön, Menü Struktur habe ich noch nie geändert, egal was ich nutze Linux, Windows, OS2 ...

Ich ändere maximal das Hintergrund Bild, dann hat man bei Neuinstallation wenig Arbeit ...
Samba HDD Sleep usw braucht man alles nur 1x, kann man im Setup auch viel einfacher an neue VDR/Ubuntu Versionen anpassen.

Channels.conf auch noch sinnvoll (manchmal läuft der VDR ja wegen einer falschen nicht)
Sonnst wüsste ich auch nichts was ich extra nutze, die Plugins haben ja ihre eigenen Setup Menüs.

Gruß
Peter

[Wirbel]

Ich hab mich mal auf den steinigen Weg eines Plugins gemacht, welches erst einmal nur Plugins managed.

Das Thema OSD in VDR ist für jemanden mit begrenzter Erfahrung im Coden wie mich schwierig, aber mal sehen ob etwas heraus kommt.
Wird aber etwas dauern.

[SurfaceCleanerZ]

Hallo Wirbel, 
Das klingt echt super! Evtl. kannst du ja doch etwas vom Plugin nutzen. 
Ich bin echt gespannt! 
Schon mal vorab vielen Dank! 
Mfg Stefan

[gb]

Hi Wirbel 

Dem geschriebenen von Stefan kann ich mich nur anschließen. Es ist halt nicht selbstverständlich und jeder Versuch bringt uns einen Schritt weiter. 

Gruss Aaron

[Wirbel]

Mal ein kurzer Status.

Ich habe für euch ein neues Plugin namens "easyvdr" begonnen.
*wenn* (!) ihr es denn benutzt wollt, dann muss es das wirklich einzige Plugin sein, welches vom VDR via commandline -P gestartet wird.

Dieses Plugin wird einen einzigen Parameter in der vdr command line haben:
-c <fullpath>

womit der Pfad zu einer Konfigurationsdatei zu diesem Plugin im ini Datei Format gemeint ist.
Falls nicht mit -c gesetzt, ist der Pfad zu dieser Datei "/etc/vdr/conf.d/easyvdr.ini".

-------------------------------
Zum "ini Datei Format":
Jede Datei in diesem Format wird verstanden als Textdatei:

Code:

[Section]
Identifier=Value

Wobei *jedes* 'Identifier=Value' Paar zu einer vorher definierten Section zugeordnet ist. Jede Zeile in der Textdatei, welche weder die Angabe einer neuen Section, oder eines Wertepaares 'Identifier=Value' ist, ist ein Fehler. Auch Paare ohne vorherige Angabe einer Sektion.
--------------------------------

Die Konfigurationsdatei des Plugins wird (zuerst) nur einige wenige Einträge haben.

Code:

[Common]
Description = easyvdr setup helper plugin
PluginConfigFile = /etc/vdr/conf.d/*_settings.ini
MainMenuEntry = easyvdr
PluginDebug = true
PluginManagerDebug = true

Erklärung zu den Einstellungen..

Code:

Common::Description -> Der Beschreibungs-Hilfetext des Plugins im Menü unter "Einstellungen/Plugins"
Common::PluginConfigFile -> Der Dateipfad zu den Einstellungen je Plugin. Das Zeichen '*' wird später durch den Namen eines Plugins wie 'control' oder 'softhddevice' ersetzt.
Common::MainMenuEntry -> Der Name des Hauptmenü Eintrags. Falls nicht gesetzt (also der ini Eintrag fehlt), heißt es 'easyvdr' - so wie das Plugin.
Common::PluginDebug -> Debug Meldungen Ein oder Aus.
Common::PluginManagerDebug -> Die Meldungen für das Laden von Plugins ein oder aus.

In der Section 'HelpText' stehen HilfeTexte für die Einstellungen, so etwas wie

Code:

"Common::PluginManagerDebug = true/false : PluginManager debug messages to stderr"

--------------------

Zu jedem zu ladendem/verwaltetem anderen Plugin (!) liest dieses Plugin dann die Einstellungen aus einer weiteren ini Datei.
Das ist per default dann "/etc/vdr/conf.d/*_settings.ini", wobei das '*' ersetzt wird durch den Name eines Plugins, z.B. "skinsoppalusikka" oder "sleeptimer".


In der Section "EasyPluginManager" dieser Datei (je Plugin!) finden sich dann folgende Einstellungen
AutoRun <- Soll dieses Plugin beim Start von VDR geladen werden? [true/false]
Stop <- Darf dieses Plugin zur Laufzeit des VDR gestoppt werden? [true/false]
Args <- Die Commandline dieses Plugins, z.B. für das satip Plugin "-d2" für zwei devices.

Beispiel für das "control" Plugin. Die Datei heißt dementsprechend also "/etc/vdr/conf.d/control_settings.ini".
[code]
[EasyPluginManager]
AutoRun = true
Stop = true
Args =
[code]

Dieses Plugin wird also:
1. bei Start von VDR geladen
2. darf gestoppt werden
3. hat eine leere Kommandozeile ""

[Wirbel]

Hier dazu der Menü Eintrag via control Plugin...

[SurfaceCleanerZ]

Hi, 
Sieht gut aus, aber ist eine zentrale Datei, wo drin steht welche Plugins zu starten sind, nicht handhabbarer? So kann man eine default Liste von Plugins mitliefern. 
Irgendwie muss noch berücksichtigt werden, dass manche Plugins als erstes oder letztes Plugin geladen werden müssen, nur als Hinweis, dynamite ist da ja ein Problem, dass in den bisherigen Skripten nebst hier nicht zu nennendem eine Sonderbehandlung bekommt. 

Dass die Beschreibung und die Plugin Parameter in einer Config Datei im Plugin stehen macht Sinn! Das klingt sehr gut!

Ob es ini oder conf Dateien sind, ist Geschmackssache... 

Klingt für mich sehr vielversprechend! Weiter so! 

Der Menüeintrag sollte vielleicht statt easyvdr eher Plugin-Setup oder so genannt werden, was meint ihr? 

Das soll keine Kritik sondern nur eine Ergänzung sein! Bloss Ich finde lieber jetzt dran denken, als später wenn fertig merken, man hat etwas übersehen. 
Mfg Stefan