VDR4Arch
Inhaltsverzeichnis |
Allgemein
VDR4Arch ist ein fertiger Paketsatz für VDR auf Arch Linux. Höchstes Ziel ist es dabei, die Regeln des Arch Linux DeveloperWikis einzuhalten.
Installation
Diese Installationsanleitung setzt direkt nach der Grundinstallation aus der Arch Linux-Wikiseite an. Solltest du jetzt noch keine lauffähige Arch Linux Grundinstallation haben beginne bitte hier
Im neu gebooteten System installieren wir zuerst die vdr4arch-keyring
# wget http://creimer.net/vdr4arch/repo/vdr4arch-keyring-20130219-1-any.pkg.tar.xz # pacman -U vdr4arch-keyring-20130219-1-any.pkg.tar.xz
und fügen anschließend das Repository an das Ende von /etc/pacman.conf
[vdr4arch] SigLevel = PackageRequired Server = http://creimer.net/vdr4arch/repos/stable
Und aktualisieren die lokale Paketdatenbank
# pacman -Sy
Über
# pacman -Sl vdr4arch
kann man die verfügbaren Pakete auflisten.
Weitere Einzelheiten können auch in der Paketübersicht nachgelesen werden.
Ausgabe über Grafikkarte
Zuerst muss de X-Server an die Ausgabe mit dem VDR angepasst werden. Dazu muss eine Konfigurationsdatei erstellt werden
# nano /etc/X11/xorg.conf.d/20-vdr.conf
mit folgendem Inhalt
Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
Option "ExactModeTimingsDVI" "True"
Option "FlatPanelProperties" "Dithering = disabled"
Option "NoLogo" "True"
SubSection "Display"
Depth 24
Modes "1920x1080_50" "1920x1080_60_0" "1920x1080_24"
EndSubSection
EndSection
Dieses Grundgerüst muss dann in Ausnahmefällen noch etwas erweitert werden:
Option "DPI" "100x100" Option "UseEdidDpi" "False"
Für Displays mit falschen DPI-Angaben
Option "CustomEDID" "DFP-0:/etc/X11/edid.bin"
Zum Einlesen einer edid.bin
Eine edid.bin erstellt man so:
# X -verbose 6 > /tmp/xlog 2>&1
Muss nach etwa 5 Sekunden mit Strg + C abgebrochen werden
# nvidia-xconfig --extract-edids-from-file=/tmp/xlog --extract-edids-output-file=/etc/X11/edid.bin
Außerdem muss in der /etc/runvdr.conf der Start des X-Servers aktiviert werden. Dazu entfernt man einfach das Kommentarzeichen vor
#XSERVER="/usr/bin/X -nolisten tcp"
Damit die Tonausgabe auch funktioniert legen stellen wir das Standard Device von ALSA in der /etc/asound.conf um.
Bei NVidia Grafikkarten sollte grundsätzlich das hier funktionieren.
pcm.!default {
type hw
card NVidia
device 7
}
Wird keine NVidia Grafikkarte benutzt, oder es sollte wider erwarten nicht funktionieren, lohnt sich ein Blick in die Deviceliste.
Dafür installieren wir alsa-utils
# pacman -S alsa-utils
und geben die Deviceliste mit
# aplay -l
aus.
**** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1] Subdevices: 0/1 Subdevice #0: subdevice #0
Softhddevice
# pacman -S nvidia runvdr-extreme vdr-softhddevice
Und in der /etc/runvdr.conf
AddPlugin softhddevice
hinzufügen.
Xineliboutput (eigenständiger VDR)
Nur aus der Erinnerung aufgeschrieben. Noch ungetestet
# pacman -S nvidia runvdr-extreme vdr-xineliboutput
Und in der /etc/runvdr.conf
AddPlugin xineliboutput -l sxfe -r 0 -V vdpau -D opengl -P tvtime:method=use_vo_driver
hinzufügen.
Xineliboutput (Client/Server)
Client/Server Betrieb mit Xineliboutput ist in VDR4Arch im Moment noch nicht vorgesehen
Ausgabe über Full-Featured
# pacman -S nvidia runvdr-extreme vdr
(vdr-dvbsddevice und vdr-dvbhddevice sind Bestandteil des vdr Paketes)
Und in der /etc/runvdr.conf
AddPlugin dvbsddevice
oder
AddPlugin dvbhddevice
hinzufügen.
Für die Technotrend S2-6400 muss natürlich noch der Treiber installiert werden
# pacman -S v4l-dvb-saa716x
und mit
# modprobe saa716x_ff
geladen werden. Nach einem Neustart übernimmt das natürlich udev.
Dann zum Herzstück von vdr4arch
# nano /etc/runvdr.conf
Das meiste in der runvdr.conf ist selbsterklärend. Eine Sache unterscheidet sich aber von anderen Distributionen VDR-Plugins, die installiert sind, werden dadurch nicht automatisch vom VDR geladen. Dazu gibt es in der runvdr.conf die AddPlugin Zeilen. Z.B. für softhddevice
Jetzt noch den VDR in für den Autostart aktivieren
# systemctl enable vdr
Und schließlich starten.
# systemctl start vdr
Optionale Einstellungen
Auf das Netzwerk warten
Für den Fall, dass ein Plugin nicht dazu in der Lage ist, selbstständig auf eine Netzwerkverbindung zu warten sollte folgendes geändert werden.
In /etc/systemd/system/multi-user.target.wants/vdr.service.d die Datei 01-wait-for-net.conf angelegt werden.
# mkdir -p /etc/systemd/system/multi-user.target.wants/vdr.service.d # nano /etc/systemd/system/multi-user.target.wants/vdr.service.d/01-wait-for-net.conf
[Unit] After=network.target
Zusätzlich muss die Netzwerkeinstellung überarbeitet werden. Dazu muss zuerst der standardmäßig startende dhcpcd aus dem Autostart entfernt werden.
# systemctl disable dhcpcd
Danach müssen wir herausfinden, wie das Netzwerkgerät heißt
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:24:1d:d5:c1:42 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.35/24 brd 192.168.178.255 scope global enp2s0
valid_lft forever preferred_lft forever
inet6 fd00::224:1dff:fed5:c142/64 scope global dynamic
valid_lft 6790sec preferred_lft 3190sec
inet6 fe80::224:1dff:fed5:c142/64 scope link
valid_lft forever preferred_lft forever
In diesem Fall fügen wir den dhcpcd devicegebunden in den Autostart ein
# systemctl enable dhcpcd@enp2s0
Beim nächsten Neustart wird jetzt so lange gewartet, bis die Verbindung tatsächlich etabliert ist und erst danach start der VDR.
VDR4Arch-Next (VDR 2.1.x)
Für die VDR-Entwicklerversion ist ein zusätzliches Repository nötig.
[vdr4arch-next] SigLevel = PackageRequired Server = http://creimer.net/vdr4arch/repos/next [vdr4arch] SigLevel = PackageRequired Server = http://creimer.net/vdr4arch/repos/stable
Das normale vdr4arch Repository muss unbedingt (wie oben gezeigt) in der pacman.conf erhalten bleiben, da nur die veränderten Pakete im Next Repository landen.
Wechsel zurück von VDR4Arch-Next nach VDR4Arch
Dieser Schritt ist grundsätzlich nicht zu empfehlen. Will man es trotzdem unbedingt machen sind einige Schritte dazu notwendig.
Zuerst muss
[vdr4arch-next] SigLevel = PackageRequired Server = http://creimer.net/vdr4arch/repos/next
aus /etc/pacman.conf entfernt werden
Danach muss der Paketspeicher von pacman geleert werden.
pacman -Sc --noconfirm
Dies ist notwendig um mögliche Konflikte durch gleichnamige Pakete zu vermeiden. Ein Beispiel
Liegt in VDR4Arch-Stable das Paket vdr-aaa-1.0-1-x86_64.pkg.tar.xz [kompiliert gegen VDR 2.0.x] liegt in VDR4Arch-Next das entsprechende Gegenstück vdr-aaa-1.0-2-x86_64.pkg.tar.xz [Kompiliert gegen VDR 2.1.x]. Wird in VDR4Arch-Stable die pkgrel hochgezählt, hat sie genau den Paketnamen, den das Paket vorher in VDR4Arch-Next hatte (vdr-aaa-1.0-2-x86_64.pkg.tar.xz [Kompiliert gegen VDR 2.0.x]).
Wechselt man in dieser Situation zurück zu VDR4Arch-Stable liegt das gleichnamige Paket aus VDR4Arch-Next noch im Paketspeicher. Dieses ist allerdings nicht gegen den VDR in VDR4Arch-Stable kompiliert und dadurch wird der Downgrade mit einem Fehler abgebrochen.
Ist der Paketspeicher geleert wird über
pacman -Syuu (Achtung zweimal "u")
der eigentliche Downgrade ausgelöst.
Selbst kompilieren
In einer Archlinux-Installation aufgesetzt auf einer virtuellen Maschine folgendes ausführen.
Installation der Entwicklungsumgebung
# pacman -S base-devel
repo-make installieren
# pacman -U http://downloads.tuxfamily.org/repomake/repo-make-1.0.0-1-any.pkg.tar.xz
PKGBUILDs auschecken
# git clone https://github.com/CReimer/vdr4arch.git # cd vdr4arch
Automatischen Buildvorgang starten
# repo-make
Die Pakete landen anschließend im neuen Verzeichnis "repo"
