VDR-Paket-Updates für Debian/Jessie

Es ist schon wieder ein ganzes Weilchen her seit dem letzten Update. Die VDR-Pakete für Debian/Jessie sind jetzt aber wieder auf einem einigermaßen aktuellen Stand. Weitere Updates folgen in kürze.

Die VDR und Plugin-Pakete verwenden nun nicht mehr den selbst gestrickten Mechanismus zum automatischen Laden der Plugins, sondern die seit VDR 2.1.7 verfügbare Möglichkeit, die Kommandozeilenparameter aus einem Config-Verzeichnis zu installieren (Besten Dank dafür auch an Lars Hanisch!).

Neue Config-Dateien

Beim Starten liest der VDR die *.conf-Dateien in /etc/vdr/conf.d in alphabetischer Reihenfolge und extrahiert daraus die Kommandozeilenparameter. Die conf-Dateien sind wie folgt aufgebaut:

# Kommentar
[name]
-a 1
-x 
--parameter=0815

Kommentarzeilen beginnen mit einer Raute. In eckigen Klammern folgt der Name des Abschnittes auf den sich die folgenden Zeilen beziehen. Es sind mehrere Abschnitte möglich. Der Name "vdr" ist reserviert für die Kommandozeilenoptionen, die den VDR selbst betreffen. Für Optionen die an Plugins übergeben werden sollen, wird der Name des Plugins verwendet - also z.B. [softhddevice] für vdr-plugin-softhddevice. Die Debian-VDR-Plugin-Pakete installieren für jedes Plugin standardmäßig eine eigene conf-Datei nach /etc/vdr/conf.avail und erzeugen einen Symlink in /etc/vdr/conf.d. Somit ist es möglich, ein Plugin einfach durch Löschen/Setzen des Symlinks zu deaktivieren/aktivieren (VDR-Neustart erforderlich!).

# Plugin deaktivieren
sudo rm /etc/vdr/conf.d/50-softhddevice.conf

# Plugin aktivieren
sudo ln -rsf /etc/vdr/conf.avail/softhddevice.conf /etc/vdr/conf.d/50-softhddevice.conf

Durch diese Umstellung sind auch einige Einstellungen, die vorher in /etc/default/vdr konfiguriert wurden (wie z.B. das Aufnahmeverzeichnis) obsolet. Diese Einstellungen sind nun in /etc/vdr/conf.d/00-vdr.conf zu finden.

Ich habe versucht, das Upgrade von alten VDR/Plugin-Versionen so reibungslos wie möglich zu machen. Theoretisch sollten alle alten Einstellungen übernommen werden. Falls beim Upgrade dennoch Probleme auftreten, lasst es mich bitte wissen.

Ein paar Default-Einstellungen haben sich ebenfalls geändert. So ist das Standard-Aufnahmeverzeichnis jetzt /var/lib/video, statt video.00. Mehrere Aufnahmeverzeichnisse werden von VDR nicht mehr unterstützt. Bei Neuinstallation wird der VDR nun automatisch als daemon gestartet, da dies der vorwiegende Einsatzfall ist und der VDR nur selten von Hand gestartet wird. Außerdem wurde das Neu-Laden der DVB-Module in der runvdr entfernt. Diese Funktion stammte noch aus Zeiten, als die DVB-Treiber alles andere als stabil waren.

Systemd / SysVinit

Neu ist ebenfalls, dass der VDR neben dem SysVinit-Script auch mit einer Service-Unit-Datei für Systemd installiert wird. Wenn Systemd als Init-System verwendet wird (Standard bei Debian/Jessie), so wird /etc/init.d/vdr ignoriert.

Im Zuge dessen ist auch der ENABLED-Parameter in /etc/default/vdr weggefallen. Um den automatischen Start von VDR zu deaktivieren, muss bei Systemd daher folgendes aufgerufen werden:

sudo systemctl disable vdr

Wenn SysVinit zum Einsatz kommt:

sudo update-rc.d vdr disable

Mit Systemd fallen auch die KEYB_TTY-Einstellungen in /etc/default/vdr weg, welche dem VDR ein spezielles Terminal zur Steuerung per Tastatur zuweisen. Um dies auch mit Systemd zu bewerkstelligen, kann das Beispiel aus /usr/share/doc/vdr/examples/switch-tty.conf installiert werden:

sudo mkdir -p /etc/systemd/system/vdr.service.d/ && \
sudo cp /usr/share/doc/vdr/examples/switch-tty.conf /etc/systemd/system/vdr.service.d/ && \
sudo systemctl daemon-reload && \
sudo systemctl restart vdr

Plugin-Paketierung

Wer eigene Plugins paktiert oder alte Plugins updated, muss darauf achten, dass diese Pakete auch eine Config-Datei in /etc/vdr/conf.avail anlegt und in postinst den dazugehörigen Symlink in /etc/vdr/conf.d erzeugt bzw. in postrm löscht. Das kann man zwar manuell machen, aber um das zu vereinfachen habe ich ein debhelper-Addon eingebaut, welches mit vdr-dev installiert wird. In debian/rules aktiviert man dieses mit:

%:
        dh $@ --with vdrplugin

Damit wird automatisch der das Anlegen/Löschen der Symlinks in den Maintainerscripten generiert und falls man keine Config-Datei explizit zur Verfügung stellt, wird eine leere Datei für das Plugin angelegt. Außerdem sorgt diese debhelper-Addon dafür, dass bei einem Update die Einstellungen aus der alten Config-Datei (/etc/vdr/plugins/plugin.*.conf) übernommen werden.

Published on 04/09/2015 at 23:57 by , tags , , , , ,

  • bei uwe 15/11/2015 at 08:17

    Danke. (Wird wohl wieder ein paar Jahre brauchen, bis ich kapiert und verinnerlicht habe, wie mein Rechner nun mit dem systemd-Kram startet) gruß, uwe


  • bei e-tobi 14/11/2015 at 13:48

    /etc/systemd/system/vdr.service.d/umask.conf:

    [Service]
    UMask=002
    

  • bei uwe 14/11/2015 at 06:38

    Hallo, danke für die Infos über das neue Verhalten. Wie bringe ich denn nun 'umask 002' aus der ehemaligen /etc/default/vdr unter um Zugriffsrechte auf die Aufnahmen anzupassen? Gruß, uwe


  • bei panik105 02/11/2015 at 19:34

    Hallo, ich mal wieder..

    danke für die Fixes, danke für den xineliboutput-Patch. Auch der Produktiv-Vdr ist inzwischen erfolgreich upgedatet und netterweise bekommt ja jetzt sogar meine RaspberryPi2 bald was mit vdr zu tun :-)

    Aber ich hätte da nochwas: evtl. könnte man den in http://www.vdr-portal.de/index.php?page=Thread&threadID=127561&s=98fd10059e318b6ee2cd61f300396a252461fa0e verlinkten Patch für softhddevice aufnehmen, er hat quasi den "Segen" des Autors.

    Tschuess.. Michael


  • bei rabe 25/09/2015 at 14:28

    Hallo, ich bin es nochmal.

    Die Fehler treten mit dem prop. Treiber Version: 352.30 nicht auf.

    Die CPU Last ist auch normal:

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    1137 vdr 20 0 2145692 154392 51112 S 3,3 1,9 0:14.77 vdr
    142 root 20 0 0 0 0 S 0,3 0,0 0:01.96 kworker/0:2

    1 root      20   0   29216   5216   3100 S   0,0  0,1   0:00.51 systemd                                                                                                         
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.00 kthreadd 
    

  • bei rabe 23/09/2015 at 08:48

    Doch zu früh gefreut!

    Ich habe festgestellt, dass jetzt ein CPU Kern auf 99% läuft und in dem Syslog folgende Meldung steht:

    Sep 22 20:04:34 vdr vdr[1130]: vovdpau: Can't create vdp device : unsupported GPU? Sep 22 20:04:34 vdr vdr[1130]: vovdpau: vdpvideomixerrender error : An invalid handle value was provided. Sep 22 20:04:34 vdr vdr[1130]: vovdpau: VDPAU was pre-empted. Reinit.

    Ich habe eine NVidia GTX 960 mit dem prop. Treiber Version: 352.41.

    Ich versuche mal mein Glück im Netz.


  • bei rabe 21/09/2015 at 17:47

    Das hat funktioniert und ich habe jetzt auch das Prinzip verstanden! :-)

    Besten Dank und beste Grüße


  • bei etobi 17/09/2015 at 23:37

    @rabe:

    Einfach in /etc/vdr/conf.d/00-vdr.conf die shutdown-Zeile "entkommentieren".


  • bei rabe 17/09/2015 at 23:12

    Vielen Dank für Deine unermüdliche Arbeit und das bereitstellen eines unabhängigen Repositorys!

    Ich hatte heute mal aktualisiert und mein VDR lies sich nicht mehr ausschalten. Meinte die Option -s würde fehlen!

    Damit war ich leider etwas überfragt und habe mein Backup wieder zurück gespielt.

    Ansonsten läuft alles prima.


  • bei etobi 08/09/2015 at 21:48

    @Stefan: Hast recht - ich hatte parallel die Stretch-Pakete gebaut und das Script hat das selbe Verzeichnis verwendet :-(

    vnsi hab ich nochmal hochgeladen, die anderen Pakete baue ich sicherheitshalber nochmal - wird aber ein Weilchen dauern.


  • bei Stefan 08/09/2015 at 21:14

    Hi,

    danke für das Update !

    Die Aktualierung von vdr-plugin-vnsiserver läuft auf einen Fehler:

    vdr-plugin-vnsiserver : Hängt ab von: libstdc++6 (>= 5.2) aber 4.9.2-10 soll installiert werden

    v5.2 von libstdc++6 kommt doch erst mit stretch, oder ?


  • bei etobi 08/09/2015 at 01:34

    Der truecolor-Patch ist jetzt auch drin.


  • bei etobi 06/09/2015 at 17:38

    @panik105: Danke für den Hinweis - Ich vermute hier wurde das extrecmenu-Plugin konfiguriert bevor das vdr-Update installiert wurde - das habe ich nicht bedacht, ist aber durchaus möglich - muss ich fixen.

    Ein Update für epg2vdr (und eepg, osdserver) folgt in kürze.

    Die order.conf wird beim Update bewusst ignoriert. Ich wollte das Update-Prozedere nicht noch komplizierter machen, als es ohnehin schon ist.


  • bei panik105 06/09/2015 at 14:45

    Super, dass du hier weitermachst..


    Ein paar Hinweise: Installation brach bei mir auf 2 Rechnern ab und lieferte für jedes zu aktualisierende Plugin:


    touch: „/etc/vdr/conf.d/50-extrecmenu.conf.dpkg-vdrplugin-enable“ kann nicht berührt werden: Datei oder Verzeichnis nicht gefunden
    dpkg: Fehler beim Bearbeiten des Archivs /var/cache/apt/archives/vdr-plugin-extrecmenu1.2.4-4amd64.deb (--unpack):
    Unterprozess neues pre-installation-Skript gab den Fehlerwert 1 zurück


    Mit einem apt-get -f install läuft es dann durch.


    epg2vdr legte als einziges Plugin keinen Link in /etc/vdr/conf.d an, ausserdem fehlte in der Datei in conf.avail die Section [epg2vdr].


    Worüber man noch fallen kann:
    Ich habe überall xineliboutput und softhddevice installiert, weil ich mich nicht entscheiden kann :-)
    Ich wechsle hin und her durch Voranstellen von "-" in /etc/vdr/plugins/order.conf, das nun nicht mehr berücksichtigt wird, d.h. bis zum Löschen des nicht benötigten symlinks in conf.d hatte ich erst mal beide Plugins geladen.


    Den Produktiv-Vdr update ich lieber erst nach dem Urlaub (in 3 Wochen).


    P.S.: ist es möglich, den TrueColorEverytime.patch (http://www.vdr-portal.de/board1-news/board101-news-archiv/p1151593-announce-nopacity-0-1-2/#post1151593) in xineliboutput aufzunehmen, damit ich das nicht immer selbst machen muss?


  • bei etobi 06/09/2015 at 12:59

    Sorry das war Blödsinn ... Versuchs erstmal mit einem dpkg-reconfigure locales. Oder wie oben beschrieben mit:

    [Service]
    Environment="LANG=de_DE.utf8"
    Environment="LC_ALL=de_DE.utf8"
    

  • bei etobi 06/09/2015 at 12:47

    @Volker: Die Blog-Software braucht mal ein Update

    Das mit VDR_LANG ist in der Tat noch ein Bug. Bis auf weiteres kannst du erstmal eine Datei /etc/systemd/system/vdr.service.d/language.conf anlegen die wie folgt aussieht:

    [Service]
    Environment="VDR_LANG=de_DE.utf8"    
    

    Das sollte eigentlich funktionieren, hab es aber noch nicht getestet. Ein Bugfix kommt im Laufe des Tages.


  • bei Volker 06/09/2015 at 10:48

    Okay, wer lesen kann ist klar im vorteil :-(

    Vergess meine Frage nach der Konfiguration der weiteren Parameter, steht ja hier oben.

    Aber wo und wie soll den VDR_LANG gesetzt werden?


  • bei Volker 06/09/2015 at 10:25

    BTW: der link "Comment Markup Help" führt ins leere.


  • bei Volker 06/09/2015 at 10:24

    Hi,

    seit dem update wird mein vdr vom systemd gestartet, ohne das runvdr script. Danach lief er auf englisch weil die Konfig in /etc/default/vdr nicht mehr eingelesen wird.

    Ich konnte das mit einer mit einer Anpassung der /lib/systemd/system/vdr.service beheben:

    EnvironmentFile=/etc/default/vdr

    Wo ich jetzt aber LANG und LCALL direkt definiert habe, VDRLANG hat nicht gewirkt.

    Mein vdr läuft jetzt wieder auf Deutsch, aber wie sollte er konfigurert werden? und was ist mit den anderen Opionen aus der /etc/default/vdr?


  • bei etobi 05/09/2015 at 18:53

    Ein "adduser vdr input" hätte eventuell auch genügt, um vdr den Zugriff auf /dev/input/eventX zu geäwhren.

    Wegen softhhdevice: da scheint die Ãœbernahme der alten Config nicht funktioniert zu haben. Kann ich leider nicht nachvollziehen.


  • bei Marcus 05/09/2015 at 17:03

    So, nochmal ich.

    Nach einem "apt-get purge vdr-plugin-softsddevice" und anschließendem "apt-get install vdr-plugin-softsddevice" geht es wieder.

    Fehler im syslog war: "ERROR: no OSD provider available - using dummy OSD!"

    Warum? Weiß ich nicht.

    Danke für die aktualisierten VDR Pakete ;-)

    VG, Marcus


  • bei Marcus 05/09/2015 at 16:35

    So, "root" gefunden, aber ich bekomme kein Bild ;-( ps ax|grep vdr zeigt nur dies "3375 ? Ssl 0:00 /usr/bin/vdr" ? Any hint+ Gruß, Marcus


  • bei Marcus 05/09/2015 at 16:05

    Sehr schön. Leider geht jetzt mit dem remote Plugin nichts mehr. Fehlende Berechtigung bei Zugriff auf /dev/input/eventX...

    Wie lass ich den VDR denn jetzt wieder als Benutzer root laufen?

    VG, Marcus


comment VDR-Paket-Updates für Debian/Jessie

Trackbacks are disabled

Powered by Publify | Photo Startup stock photos