Verständnisfrage zu /etc/vdr/conf.d

Die conf.d Konfiguration greift nur, wenn man dem VDR keinerlei Argumente mitgibt. Und ja, man muss jedes Plugin, das geladen werden soll, explizit eintragen.

Ja, für jedes Plugin, dass geladen werden soll, braucht es eine Datei. Bei älteren Versionen musste man die ja auch in der runvdr angeben, auch wenn sie keine Parameter haben. Ziel des ganzen ist es - so wurde mir es erklärt - dass man garkeine runvdr mehr benötigt, sondern alle Parameter in den conf-Dateien hinterlegt und dann nur noch zb /usr/local/bin/vdr startet. Es geht übrigens nicht, dass man die VDR Parameter in der conf Datei ablegt, die Plugins aber per Kommandozeile in der runvdr hinterlegt. Kann denn bei dir User martin die conf-Dateien lesen?

Zitat von TheChief

Ja, für jedes Plugin, dass geladen werden soll, braucht es eine Datei.

Nein. Das ist nur schöner und ich habe nach wie vor die Hoffnung das einige Plugin-Entwickler irgendwann schöne vorbereitete Konfig-Dateien mit anbieten.

Man könnte aber auch sowas machen:

[vdr]
-w 60
-u martin
-c /var/lib/vdr
-s /usr/local/bin/vdrpoweroff.sh 


[softhddevice]
-a hw:1,7
-p hw:1,7
-d :0 -f
-v vdpau

Alles in einer Datei.

Wenn man den Plugin-Teil in einer eigenen Datei hat, dann könnte man das Plugin aber recht einfach durch Umbenennen dieser Config-Datei abschalten. Das geht in der "nur eine Datei"-Variante nicht so einfach. Hier müsste der *ganze Block* für das Plugin kommentiert werden.

Ah gut zu wissen. Einzelne Dateien find ich schöner. Die liegen bei mir jetzt in conf.avail und werden mittels symlink nach conf.d aktiviert. Hatte Copperhead so vorgeschlagen.

Wird so unter vdr4arch auch schon einige Zeit gehandhabt.

Die Dateien werden nach Name sortiert und dann quasi wie eine große Datei behandelt. Wenn man will, kann man sogar einen Abschnitt über mehrere Dateien verteilen. Ist aber sicher nicht sinnvoll.

Für die selbst-bauenden vdr-Nutzer und einer handvoll Plugins kommt man sicherlich mit einer Datei gut zurecht, Distributoren dürfen sich dann über eine Datei pro Plugin freuen, ähnlich wie es Debian ja schon gemacht hat, nur dass man dort über die order.conf die Reihenfolge und Deaktivierung festlegt. Das kann man dann über symlinks regeln. Ein vdrctl-Tool schwebt mir da noch im Kopf rum (oder hat das schon jemand angefangen?), mit der man dann einfach Plugins (de)aktivieren kann.

Und mit "vdr --showargs" kann man sich die Konfiguration anzeigen lassen.

Lars

mini73

Da könnte man sich an a2enmod vom Apache2 Webserver orientieren. Dort macht man ja fast das gleiche, es werden Symlinks von mods-available nach mods-enabled angelegt. Das gleiche geht auch für sites und configs.

Zitat von mini73

Ein vdrctl-Tool schwebt mir da noch im Kopf rum (oder hat das schon jemand angefangen?), mit der man dann einfach Plugins (de)aktivieren kann.

Ich habe mir schon ein paar Gedanken gemacht, wie man das lösen könnte. Ich würde das mit Perl lösen. Von der Steuerung direkt angelehnt, an systemctl von systemd.

Also "vdrctl list", "vdrctl enable", "vdrctl disable". Möglicherweise noch "edit"

Schwierig wird das wenn man Plugins doppelt lädt.
Da würde ich vorschlagen, dass man im Regelfall "vdrctl enable softhddevice" erlaubt. Sollte es zwei Dateien mit softhddevice in conf.avail geben, ist dann eben nur noch der volle Dateiname der conf erlaubt.

Gäbe es also eine 50-softhddevice.conf und eine 51-softhddevice.conf wird in "list" beide angezeigt. "vdrctl enable softhddevice" liefert aber einen Fehler. "vdrctl enable 50-softhddevice" funktioniert aber weiterhin.

Nicht unterstützen würde ich das Ändern der Pluginreihenfolge. Das wird über den Dateinamen der Conf geregelt.
Schwierig ist es da auf einen Nenner zu kommen zwischen den Distributionen.

Ich denke wahrscheinlich schonwieder viel zu kompliziert.

Spielt die Reihenfolge eigentlich noch eine Rolle? Muss beispielsweise satip, damit Devices erstellt werden, oder das böse zuerst geladen werden?

Es gibt nur sehr wenige Plugins, für die die Reihenfolge eine Rolle spielt. In erster Linie kenne ich da dynamite.

Ob Perl oder eine andere Sprache ist mir egal, zuerst müsste man die Syntax definieren, aber wir schweifen ab.

Lars

Das Plugin-Handling ist bei Gentoo recht gut gelöst und sie lassen sich einfach per Befehl aktivierten oder deaktivieren. Hier im Forum tummeln sich ja die Verantwortlichen für die Ebuilds rum. Wäre gar nicht schlecht, wenn sich die Maintainer der unterschiedlichen Distries mal zusammen hocken und sich kurzschließen, das wäre bestimmt sehr produktiv. Es ist doch vollkommen bescheuert, wenn jeder sein eigenes Süppchen kocht.
Ja ich weiss, OT, könnte aber in ein neues Thema.

Die Variante mit den einzelnen Plugin Dateien die per Symlink zu aktivieren finde ich zur Zeit mit am Besten.

Man hat durch die beiden Verzeichnisse einen Überblick, der aktivierten und deaktivierten Plugins. In einer Datei wäre das wieder schwieriger. Es ist sehr einfach zum Handhaben und wie bereits gesagt in anderen Systembereichen durchaus anzutreffen wie beim Indianer. Die Sortierung, wer es will oder braucht, ist auch möglich.

Im Prinzip also genauso wie bei Verwendung von runvdr-extrem. Fein, dann muss ich nicht viel ändern

Hi,
Das hat easyvdr2.0 ja mittels setup-Plugin drin. Plugins lassen sich bequem per Webseite aktivieren und sogar installieren. Neuerdings sogar mehrere auf einmal. Läuft laut wolfi auch mit 2.1.8 auch.
MfG Stefan

Gesendet von meinem HTC One mit Tapatalk 2

Bisher war es ja immer recht einfach die Reihenfolge der Plugins und damit die Menueinträge im OSD durch die Stellung in der Commandline festzulegen. Ich hatte das immer so sortiert, daß das Mail plugin immer durch Taste 5 (blind) gestartet werden konnte. Wenn man jetzt die Plugin.conf Dateien einzeln hat. Hängt dann die Reihenfolge vom Namen der conf-files ab? Also sollte man den Dateien nicht unbedingt den Namen des Plugins alleine mitgeben sondern noch einen lexikalischen prefix, um wieder eine vorgegeben Reihenfolge zu gewärleisten?

Oder hat sich auch im Plain VDR das Menuhandling geändert. Ich hab nicht immer so alle Details verfolgt (weil eigentlich wollte ich ja Filme gucken), aber nun muß man sich ja mal für die nächste Stable mal wieder damit beschäftigen....

Gruß
msv

Ein Prefix ist sinnvoll und bei vdr4arch auch vorhanden: https://github.com/VDR4Arch/vd…/plugins/vdr-softhddevice

Damit kann dann für die wenigen Plugins, die früher geladen werden müssen, auch ein kleinerer Prefix genutzt werden.

Der VDR soll ja "irgendwann" auch noch ein anpassbares Hauptmenü bekommen. Dann wäre der Workaround über die Plugin-Reihenfolge hier nicht mehr nötig.

Ja, Präfix sollte man benutzen. Die vdr.conf sollten "00-" bekommen, die Plugins "50-". Ein Plugin, das weiß, dass es später geladen werden möchte, nimmt dann "90-", und ein Plugin, das man früher laden möchte, bekommt dann eine Zahl kleiner als 50.

Lars.

Ich werde die Tage noch eine ausführlichere Doku mit "best practices" schreiben. Das will ich noch vor dem vdr 2.2 fertig haben...

Lars.

Wenn man schon dabei ist, wäre es nicht auch sinvoll, etwas ähnliches für die setup.conf zu tun und die Parameter der Benutzer für die verschiedenen Plugins auch in einzelne Dateien speichern, anstatt alles in die setup.conf zu stecken.