Aufsetzen eines schlanken HD-VDRs unter Debian mit passender Entwicklungsumgebung

Grundinstallation (für Produktiv-VDR und Entwicklungssystem gleichermaßen)

Zum Zeitpunkt des Schreibens gab es keine Installationsmedien für Debian-Sid, weshalb die Installation mit Stable-Netinst erfolgt und später auf Sid gewechselt wird.
Also mit Netinst booten und dem Installer folgen (Sprachauswahl, etc.). Als Benutzer wird ein persönlicher Benutzer verwendet, nicht vdr (der wird später angelegt!).
Bei Softwareauswahl wird alles abgewählt (also Vorgabe von Desktop und Standard entfernen). Nach Abschluss der Installation grub installieren lassen und neu booten.

Rechner zugänglich machen

Ich arbeite am liebsten an „meinem“ Desktop, d.h. als erstes sorgen wir dafür, dass der Rechner per Fernwartung bedient werden kann. Um halbwegs sicher zu sein, verwenden wir ssh.

apt-get install openssh-server

Wer Produktiv und Entwicklungssystem auf einem Rechner mit verschiedenen Partitionen betreibt, mag vielleicht mit statischen IP-Adressen arbeiten, wobei Produktiv- und Entwicklungssystem unterschiedliche Adressen bekommen. Danach kann die Konsole mit exit geschlossen werden. Den Rest erledigen wir aus der Ferne, von unserem Desktop aus.

Versionswechsel

Per ssh verbinden wir uns jetzt mit dem Rechner. Wer mag, kann gleich die .bashrc an seine Vorlieben, bzw. seinen Geschmack anpassen. Bei mir gibt es folgende Einträge:
Zuerst aktiviere ich die Farbausgabe für ls:

export LS_OPTIONS='--color=auto'
eval "`dircolors`"
alias ls='ls $LS_OPTIONS'

Dann gibt es ein paar Kürzel für nützliche ls-Varianten (ll – für die Langform, la für die Langform mit versteckten Dateien und ltr für die zeitlich sortierte Langform):

alias ll='ls $LS_OPTIONS -l'
alias la='ls $LS_OPTIONS -la'
alias ltr='ls $LS_OPTIONS -ltr'

Jetzt folgen ac für die Debian-Paketsuche, ai zum Installieren, ii für die Prüfung, ob ein Paket bereits installiert ist und pi für die Paketinfo.

alias c='clear'
alias ac='apt-cache -n search'
alias ai='apt-get install'
alias ii='dpkg -l | grep -i'
alias pi='apt-cache show'
alias dist-upgrade='apt-get update && apt-get dist-upgrade'

Aktiviert werden die neuen Einstellungen über

. ./.bashrc

Danach widmen wir uns wieder der Grundinstallation:
Dazu werden in der Datei /etc/apt/sources.list alle Vorkommnisse von lenny gegen sid ausgetauscht. Die Einträge von security.debian.org und [/font]volatile.debian.org[/font] werden auskommentiert, bzw. gelöscht, da die nur für stable existieren. Somit sieht die neue sources.list etwa so aus:

deb http://ftp.de.debian.org/debian/ sid main non-free contrib
deb-src http://ftp.de.debian.org/debian/ sid main non-free contrib

Mit einem

apt-get update && apt-get dist-upgrade

starten wir den Versionswechsel. Wenn der durchgelaufen ist, kann mit

upgrade-from-grub-legacy

auf den neuen Bootmanager gewechselt werden. Wer mag, kann vorher noch booten, um zu sehen, ob's auch klappt.

Firmware für r8169

Beim Versionswechsel kommt die Warnung, dass die Firmware für r1869 fehlen würde. Der Kernel wird gerade aufgeräumt, sodass einige Firmware nach non-free musste. Laut Aussage der Debian-ML funktioniert ein Treiber auch weiterhin, der bisher getan hat.
Bei mir traf das zu – ich musste keine Firmware nachinstallieren.

Benutzer anlegen

zuerst die Gruppe vdr anlegen:

addgroup -system vdr

Das -system bewirkt, dass die Gruppe die Nummer < 1000 erhält. Anschließend wird noch der Benutzer vdr angelegt:

adduser -system -ingroup vdr vdr

Basispakete installieren

Ich habe jetzt verschiedene Konstellationen durchgespielt und es sieht so aus, als wäre die Kombination aus nodm und fluxbox schlank und zuverlässig – deshalb für mich die erste Wahl. Vi ist meine Hausmarke, wer es nicht mag, kann ja seinen Lieblingseditor eintragen.

cat > basePkgs.list << EOF
less
alsa-utils
bzip2
xterm
xorg
nodm
x11-xserver-utils
ffmpeg
fluxbox
mc
vim
nfs-common
nfs-kernel-server
pciutils
EOF


apt-get install $( < basePkgs.list )

Ballast abwerfen

Einige Pakete werden bei einem „normalen“ VDR nicht unbedingt benötigt. Manche Pakete werden auf dem Entwicklungssystem später wieder mit installiert, aber das ist ok so. Liste bitte überprüfen und nach eigenem Geschmack anpassen.

cat > pkgs.2remove << EOF
aptitude
dictionaries-common
ding
doc-linux-de
ghostscript
ghostscript-x
gs-common
gsfonts
info
ingerman
ispell
javascript-common
man-db
manpages
manpages-de
manpages-dev
mime-support
nano
radeontool
trans-de-en
vim-tiny
wngerman
wwwconfig-common
EOF


apt-get purge $( < pkgs.2remove )


apt-get autoremove

Paketrepository um e-tobi und multimedia erweitern

Schlüssel für e-tobi holen und einbinden.

wget --quiet http://e-tobi.net/vdr-experimental/pool-lenny/binary/base/e-tobi-keyring_2008.03.08_all.deb
dpkg -i e-tobi-keyring_2008.03.08_all.deb

Da wir selbst bauen, kommentieren wir die deb-Zeilen aus und verwenden nur die deb-src Zeilen:

cat > /etc/apt/sources.list.d/vdr.list << EOF
# release = vdr-experimental | vdr-testing
# dist    =  etch | lenny | sid
# section = base | backports | addons | vdr-standard | vdr-extensions |vdr-multipatch
# wir sind nur an Quältexten interessiert ...
#deb http://e-tobi.net/vdpau-xine1.1-vdrdevel sid base vdr-multipatch
#deb http://e-tobi.net/vdpau-xine1.1 sid base vdr-multipatch


deb-src http://e-tobi.net/vdpau-xine1.1-vdrdevel sid base vdr-multipatch
deb-src http://e-tobi.net/vdpau-xine1.1 sid base vdr-multipatch


# keine amd64-Pakete
#deb http://e-tobi.net/vdrdevel-experimental lenny base vdr-multipatch
#deb http://e-tobi.net/vdr-experimental lenny addons


deb-src http://e-tobi.net/vdrdevel-experimental lenny base vdr-multipatch
deb-src http://e-tobi.net/vdr-experimental lenny base addons vdr-multipatch
EOF

e-tobis vdr Pakete haben Priorität vor Debian Paketen ...

cat > /etc/apt/preferences.d/etobi.prefs << EOF
Package: *
Pin: release o=e-tobi.net
Pin-Priority: 1001
EOF

Schlüssel für Debian-multimedia.org holen ...

wget --quiet http://www.debian-multimedia.org/pool/main/d/debian-multimedia-keyring/debian-multimedia-keyring_2008.10.16_all.deb
dpkg -i debian-multimedia-keyring_2008.10.16_all.deb

Debian-multimedia.org einrichten

cat > /etc/apt/sources.list.d/debian-multimedia.org.list << EOF
deb http://www.debian-multimedia.org sid main
deb-src http://www.debian-multimedia.org sid main
EOF

aufräumen ...

rm *.deb
apt-get update

Ab hier trennen sich die Installationswege von Entwicklungssystem und Produktivsystem. Da unser Produktivsystem von den Ergebnissen unseres Entwicklungssystems abhängt, beschäftigen wir uns zuerst mit dem Entwicklungssystem und dem Bau der eigenen Pakete.

Beim Produktivsystem wird noch ein weiteres Repository hinzugefügt, doch dazu später mehr.

Entwicklungssystem

Ein HD-Vdr ist ein komplexes Client-Server Gebilde, bei dem quasi 2 VDR Instanzen vorkommen. Bei der Entwicklung trennen wir auch auf zwischen dem Backend, also der VDR-Instanz, die die DVB-Daten empfängt, oder Aufnahmen zum Abspielen aufbereitet und dem Frontend, welches Bild und Ton ausgibt und Tastatureingaben entgegen nimmt und an das VDR-Backend weiterleitet. Front- und Backend können auf einem Rechner oder auf verschiedenen Rechnern laufen. Wenn beide Teile auf dem gleichen Rechner laufen sollen, muss dies z.B. beim Kernelbau etc. berücksichtigt werden. Ansonsten kann man jede Schiene für sich bauen.

Basispakete für die Entwicklung

cat > devBase.list << EOF
autoconf
automake
automake1.9
build-essential
ccache
checkinstall
cvs
devscripts
doxygen
gettext
git-core
git-buildpackage
kernel-package
libopenjpeg-dev
libtool
libx11-dev
libncurses-dev
mercurial
pkg-config
pristine-tar
subversion
texi2html
yasm
EOF


apt-get install $( < devBase.list )

Backend

Das Backend braucht die DVB-S2-Treiber für den Empfang und somit einen selbstgebauten Kernel.

Kernelbau für Backend

Wir verwenden jeweils den neuesten Kernel von www.kernel.org – im Augenblick ist 2.6.32.2 aktuell.

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.32.2.tar.bz2
tar -jxf linux-2.6.32.2.tar.bz2
cd linux-2.6.32.2

Wer neu ist im Kernelbau, fängt am Besten mit der Konfiguration des laufenden Systems an:

cp /boot/config-2.6.32-trunk-amd64 .config
make oldconfig

Dabei alle Vorgaben, bei denen man es nicht besser weiß, einfach so akzeptieren, wie sie angeboten werden. Wer mag kann die entstandene .config sichern, sodass man für die spätere Entschlackung des Kernels eine funktionierende Ausgangsbasis hat. Bei einem make mrproper (make clean für den Kernel) wird die .config gelöscht.

Jetzt wieder für alle – wir starten die Menüauswahl des Kernels und deaktivieren den kompletten Bereich „multimedia support“ unter „device drivers“.

make menuconfig

Denn der multimedia-Bereich wird später von dem DVB-S2-Treiber abgedeckt, den wir auch selbst bauen wollen. Wenn wir den Bereich im Kernel nicht deaktivieren, kommt es später zu Konflikten.
Der Kernelbau ist eine sehr langwierige Geschichte – wer's also etwas flotter mag, kann make die Anzahl der CPUs mitteilen:

export CONCURRENCY_LEVEL=4

Wer vorhat regelmäßig den Kernel zu bauen, baut die Zeile am besten ins System ein:

cat >> /etc/profile << EOF
export CONCURRENCY_LEVEL=4
EOF

Den Kernelbau starten wir mit:

make-kpkg --append-to-version -vdr --initrd kernel_image kernel_headers

Danach installieren wir den neuen Kernel und das Headers-Paket auch gleich mit:

cd /usr/src
dpkg -i linux-image-2.6.32.2-vdr*.deb
dpkg -i linux-headers-2.6.32.2-vdr*.deb

Vor dem Booten kontrollieren wir, ob auch ein initrd.img-2.6.32.2-vdr angelegt wurde. An der Ecke scheint es gerade etwas zu klemmen, sodass evtl ein

update-initramfs -ck 2.6.32.2-vdr
update-grub

nachgeschoben werden muss. Anschließend booten wir, um den Kernel zu aktivieren.

Eigenes Repository aufsetzen

Die Pakete, die wir auf dem Entwicklungssystem bauen, sollen ja wie normale Debianpakete auf dem Produktivsystem installiert werden können. Dazu packen wir alle *.deb-Dateien in eine Verzeichnis-Struktur, die von apt-get akzeptiert wird.




Ein Repository kann per ftp[1][2], http[3] oder per Dateiprotokoll veröffentlicht werden. Wenn man Entwicklungssystem und Produktivsystem auf einem Rechner (z.B. auf 2 verschiedenen Festplatten oder Partitionen) aufbaut, ist das Dateiprotokoll die einfachste Möglichkeit. Letzteres verwende ich.




Bei Debian liegen Daten, die anderen Rechnern über Dienste zur Verfügung gestellt werden unter /srv – deshalb leben wir unsere Paketquelle auch dort an. Da die Anzahl unserer selbstgebauten Pakete überschaubar bleibt, legen wir nur ein gemeinsames Pool-Verzeichnis an:

mkdir -p /srv/debian/dists/sid/main/binary-amd64
mkdir -p /srv/debian/pool

Fehlt noch eine Beschreibung für unsere Paketquelle:

cat > /srv/debian/dists/sid/Release << EOF
Origin: myself
Label: the freshest sauces around
Suite: unstable
Codename: sid
Date: Fri, 19 Dec 2009 06:00:00 UTC
Archtectures: amd64
Components: main
Description: my own vdr packages – not released
EOF

Anschließend veröffentlichen wir den Pfad unserer Paketquelle für div. Tools:

cat >> /etc/profile << EOF
export APT_REPOSITORY='/srv/debian'
EOF

Jetzt legen wir uns noch ein script an, mit dem wir unsere Paketquelle aktualisieren können:

vi /usr/local/bin/update-repository
i

Den folgenden Skript-Inhalt in den Editor einfügen und mit :wq speichern.

#!/bin/sh
arch=amd64
release=sid
if [ „x$APT_REPOSITORY“ == „x“ ]; then
   echo „no repository root defined! Please set APT_REPOSITORY“
   exit -1
fi
echo „gonna refresh apt-repository: $APT_REPOSITORY“
cd $APT_REPOSITORY
dpkg-scanpackages pool /dev/null | gzip -9c > dists/$release/main/binary-$arch/Packages.gz
dpkg-scanpackages pool /dev/null | bzip2 > dists/$release/main/binary-$arch/Packages.bz2

Anschließend das Skript noch ausführbar machen

chmod +x /usr/local/bin/update-repository

Jetzt können wir es gleich ausprobieren:

export APT_REPOSITORY='/srv/debian'
cd /usr/src
mv linux-*.deb $APT_REPOSITORY/pool
update-repository

Dabei sollte der Hinweis kommen, dass 2 Pakete in Ausgabedatei geschrieben wurden.

DVB-S2-Treiber

Hier müssen wir zuerst die „alte“ Firmware rausschmeißen, sonst bricht nachher die Installation mit einem Fehler ab:

apt-get purge firmware-linux-free

Dann bauen wir die neuen Treiber mit:

cd /usr/local/src
hg clone http://mercurial.intuxication.org/hg/s2-liplianin/
cd s2-liplianin
cd linux/include/linux
ln -s /usr/src/linux-headers-`uname -r`/include/linux/compiler.h .
cd ../../..
make -j 4

Wer eine abweichende Anzahl von CPUs hat, sollte die Ziffer nach -j daran anpassen.

Jetzt kommt die erste Änderung, die unsere eigene Paketquelle betrifft. Anstatt make install auszuführen, fangen wir alle Ausgaben ab und bauen davon ein Debianpaket. Glücklicherweise gibt es bei Debian das Hilfsmittel dazu bereits frei Haus:

checkinstall make install

checkinstall bietet die Möglichkeit, mittels --review-control sich die erzeugte control-Datei anzuschauen, da aber die Paketerstellung scheitert, wenn man die control-Datei zu diesem Zeitpunkt noch ändert, lasse ich den Parameter lieber weg. Sämtliche Einträge lassen sich über das Menü von checkinstall bearbeiten ...

Zuerst gibt es den Hinweis, dass es bei dem Paket noch keine Dokumentation gibt, verbunden mit der Frage, ob die Vorgabedoku erstellt werden soll. Hier ist y eine gute Antwort. Anschließend kann man eine Beschreibung für das zu erstellende Paket eingeben.
Wir geben hier DVB S2-Treiber vom <Datum der Erstellung> ein. Eine leere Zeile beendet die Beschreibung. Auch dieses Paket kommt in unsere Paketquelle:

cp *.deb $APT_REPOSITORY/pool
update-repository
dpkg -i dvb-s2-liplianin*.deb

Aufräumen vor dem Neubau aller Pakete

Wenn die Pakete neu gebaut werden sollen (weil sich was geändert hat oder ein Fehler auftrat), muss vorher etwas aufgeräumt werden. Bei debian-spezifischen Bau der Pakete werden Änderungen protokolliert und es werden noch weitere Dateien unter /usr/local/src erstellt. Falls ein Fehler die Ursache für den Neubau ist, könnten diese Zwischendateien für Probleme sorgen.




Deshalb setzen wir vor dem (Neu-)bau der Pakete folgenden Befehl ab:

cd /usr/local/src
rm *

Wichtig dabei, dass rm keinerlei Optionen erhält, insbesondere kein -r denn wir wollen ja die Verzeichnisse unterhalb von /usr/local/src behalten.

VDR für Backend bauen

Wer beim Frontend libxine-1.2 einsetzen will, sollte den Bau von xine vorziehen, denn das Plugin xineliboutput hat eine Abhängkeit auf libxine-dev. Wenn wir jetzt eine libxine-dev installieren und später beim Frontend die libxine selbst bauen – gibt es Probleme.
Da bei Quelltext-Paketen nicht zwischen den Versionen 1.6x und 1.7x unterschieden wird, schreiben wir die Pakete als vdr-Pakete und nicht als vdrdevel-Pakete – auch wenn wir letzteres wollen. Liste der Plugins bitte an eigenen Geschmack anpassen.

cat > backendPlugins.list << EOF
vdr-plugin-dvd
vdr-plugin-dvdselect
vdr-plugin-epgsearch
vdr-plugin-markad
vdr-plugin-skinelchi
vdr-plugin-xineliboutput
EOF

Damit können wir die Quelltexte ausfassen:

cd /usr/local/src
apt-get source vdr $( < ~/backendPlugins.list )

Gleich noch die Abhängigkeiten für den Bau der Pakete auflösen.

apt-get build-dep vdr $( < ~/backendPlugins.list )

Beim Bau der aktuellen VDR-Pakete werden die Quältexte beim Bau verändert. Dafür benötigen wir das Skript make-special-vdr:

apt-get source make-special-vdr
cp make-special-vdr-1.4/make-special-vdr /usr/local/bin
chmod +x /usr/local/bin/make-special-vdr

Der Bau von vdr und Plugins ist ne Menge Tipparbeit – zumindest die Debian-Variante. Um Tippfehler o.ä. zu vermeiden und auch hier wiederholbare Ergebnisse zu bekommen, legen wir uns wieder ein Skript an:

vi /usr/local/bin/buildVDR
 i

Danach wieder den Skript-Inhalt in den Editor einfügen und mit :wq beenden.

#!/bin/bash
# set -x
vdr_package=`ls -l | grep ^d | awk '{ print $9; }' | grep "^vdr-1"`
vdr_plugins=`ls -l | grep ^d | awk '{ print $9; }' | grep "^vdr-plugin"`
vdr_src_dir='/usr/local/src'
debug=1


if [ "x$1" != "x" ]; then
   debug=0
fi


if [ "x$APT_REPOSITORY" == "x" ]; then
   echo "no repository root defined! Please set APT_REPOSITORY"
   exit -1
fi


echo "gonna build $vdr_package"
if [ "x$debug" != "x1" ]; then
   pkgdir="$vdr_src_dir/$vdr_package"
   cd $pkgdir
   PATCHVARIANT=multipatch SPECIAL_VDR_SUFFIX=devel fakeroot dpkg-buildpackage -b -uc -tc -Rmake-special-vdr
   # need to install vdr immediatelly, as all plugins rely on it
   cd ..
   dpkg -i vdrdevel_1.7.*.deb
   dpkg -i vdrdevel-dev_1.7.*.deb
fi


echo "build plugins for: $vdr_package"
for vdrpkg in ${vdr_plugins}; do
   echo "gonna build $vdrpkg"
   if [ "x$debug" != "x1" ]; then
      pkgdir="$vdr_src_dir/$vdrpkg"
      cd $pkgdir
      PATCHVARIANT=multipatch SPECIAL_VDR_SUFFIX=devel fakeroot dpkg-buildpackage -b -uc -tc -Rmake-special-vdr
   fi
done


if [ "x$debug" != "x1" ]; then
   echo "buid done - gonna update repository ..."
   cd /usr/local/src
   cp *.deb $APT_REPOSITORY/pool
   update-repository
fi
echo "done."

Fehlt noch das Skript ausführbar zu machen:

chmod +x /usr/local/bin/buildVDR

Wenn das Script kontrolliert und ausführbar gemacht wurde, können wir es erst testen und dann den Bau starten:

buildVDR
buildVDR really

Das Skript baut alle Pakete, kopiert sie in unsere Paketquelle und aktualisiert diese. Bei mir kommt die Meldung, dass 15 Pakete in die Ausgabedatei geschrieben wurden. Bei abweichenden Plugins ist die Zahl natürlich eine andere.

Hilfsmittel für die Kanalsuche bauen

Die Kanallisten kann man sich von irgendjemand aus dem Netz besorgen, oder man lässt den Rechner selbst rausfinden, welche Kanäle verfügbar sind. Dazu brauchen wir das Hilfsmittel von Wirbel:

cd /usr/local/src
wget http://wirbel.htpc-forum.de/w_scan/w_scan-20091118.tar.bz2
tar -jxf w_scan-20091118.tar.bz2
cd w_scan-20091118
./configure
make

Danach bauen wir uns wieder ein Päckchen:

checkinstall make install
cp *.deb $APT_REPOSITORY/pool
update-repository

Frontend

Das Frontend braucht z.B. die VDPAU-Treiber und ein xine-System, welches diese Treiber verwendet.

Hilfsmittel für die Kanalsuche bauen

Der Nvidia-Treiber benötigt „nur“ die Kerneldeklarationen, d.h. falls das Frontend auf einem separaten Rechner laufen soll, ist kein Kernelbau notwendig. Es genügt ein

apt-get install linux-headers-2.6.32.2-trunk-amd64

Kernelversion ggf. an den verwendeten Kernel anpassen.

NVIDIA-Treiber installieren

Wer den Treiber nicht selbst übersetzen (lassen) will, kann den von e-tobi nehmen:

apt-get install nvidia-glx-dev

Bei wem das nicht funktioniert (Abhängkeitsproblem), oder wer den neuesten Treiber von NVidia nehmen möchte (auf Datum achten, da Nummerierung zwischen stable und unstable verschieden ist) installiert wie folgt (z.Z. ist 190.53 der aktuellste Treiber):

cd /usr/local/src
mkdir nvidia
cd nvidia
wget ftp://download.nvidia.com/XFree86/Linux-x86_64/190.53/NVIDIA-Linux-x86_64-190.53-pkg2.run
sh NVIDIA-Linux-x86_64-190.53-pkg2.run

Nach der Installation kann man über man nvidia-xconfig Informationen über die Konfigurationsmöglichkeiten des XServers erhalten. Ob der Treiber geladen und aktiv ist, kann man so rausfinden:

grep NVIDIA /var/log/syslog


   ... NVRM: loading NVIDIA UNIX x86_64 Kernel Module  190.53  Wed Dec  9 15:29:46 PST 2009

XServer aktivieren

Um nodm zu aktivieren, muss die Datei /etc/default/nodm angepasst werden:

NODM_ENABLED=true
NODM_USER=vdr

Bevor wir den Xserver starten kontrollieren wir noch die /etc/X11/xorg.conf – im Abschnitt „Device“ sollte nvidia als Driver eingetragen sein. Im Abschnitt Monitor sollten die Werte von HorizSync und VertRefresh den Werten des angeschlossenen Monitors (siehe Handbuch des Monitors) entsprechen! Dann sollte noch das Composite abgeschaltet werden:

cat >> /etc/X11/xorg.conf << EOF


Section "Extensions"
    Option         "Composite" "Disable"
EndSection
EOF

cat >> /etc/profile << EOF
export DISPLAY=':0.0'
EOF

cat >> /home/vdr/.xhosts << EOF
127.0.0.1
EOF

Anschließend ein /etc/init.d/nodm start oder rebooten, je nach Gusto.

vdpinfo bauen

Wir wollen ja nicht nur Pakete übersetzen, sondern auch prüfen, ob der Bau einen Wert hatte ...
vdpinfo ist dafür da, die Installation des Nvidia-Treibers zu überprüfen.

cd /usr/local/src
wget http://www.cs.rug.nl/~wladimir/vdpinfo/vdpinfo-0.0.5.tar.gz
tar -zxf vdpinfo-0.0.5.tar.gz
cd vdpinfo
make
cp vdpinfo /usr/local/bin

Vor dem Test müssen wir noch den Xserver bekannt machen

export DISPLAY=':0.0'

Danach können wir den Test starten mit vdpinfo
Wenn die Fähigkeiten der Grafikkarte angezeigt werden, sollte der Nvidia-Treiber funktionieren.

VDR für Frontend bauen

Wer xine von Debian nehmen kann und mag, braucht nicht viel zu bauen.
Für das Frontend scheint es keine Unterschiede zwischen 1.6x und 1.7x zu geben. Demzufolge bauen wir ein Frontend für 1.6:

cd /usr/local/src/vdr-plugin-xineliboutput-1.0.4+cvs20091215.2049
PATCHVARIANT=multipatch fakeroot dpkg-buildpackage -b -uc -tc
cp xine*.deb $APT_REPOSITORY/pool
update-repository

Da die Ergebnisse nicht gerade berauschend waren, entschloss ich mich die xinelib1.2 auch selbst zu bauen. Dafür gibt es aber noch keine VDR-Anpassung für Debian, sodass etwas Handarbeit notwendig ist.

Bau von ffmpeg

Das Herz der meisten Videoanwendungen heißt ffmpeg und dessen Entwicklung schreitet viel schneller voran, als die ganzer Betriebssysteme. Deshalb macht es Sinn, diese Entwickelung aufzugreifen und zu integrieren. Seit ich ffmpeg selbst gebaut habe, laufen zumindest die „normalen“ Sender zufriendenstellend. Wir holen die Quellen mit

cd /usr/local/src
apt-get source ffmpeg

X264 ist der wichtigste Codec für HD-Video und der wird von ffmpeg verwendet. Also müssen wir den zuerst bauen. Dazu klauen wir uns die Bauanleitung vom offiziellen Debian-Paket:

apt-get source libx264
rm x264*
git clone git://git.videolan.org/x264.git
cp -a x264-0.svn20091125/debian x264/debian
rm -rf x264-0.svn*
cd x264

Anschließend laden wir die Datei debian/rules in den Editor und erweitern confflags (Zeile 30) um:

--enable-asm und --enable-pic

Die extra-cflags exportieren wir ins Environment und bauen das Paket:

export CFLAGS=“-mtune=native -march=native -mfpmath=sse -O4 -pipe"
fakeroot dpkg-buildpackage -uc -tc
cd ..
dpkg -i libx264-dev_0.svn20091125-0.1_amd64.deb
dpkg -i libx264-79_0.svn20091125-0.1_amd64.deb
dpkg -i x264_0.svn20091125-0.1_amd64.deb
mv {lib,}x264*.deb $APT_REPOSITORY/pool
update-repository

Genauso verfahren wir mit dem ffmpeg-Paket. Wir nehmen die Quellen von svn und klauen uns die Bauanleitung vom offiziellen Paket:

cd /usr/local/src
svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg.svn
cp -a ffmpeg-dmo*/debian ffmpeg.svn/debian
rm ffmpeg*
rm -rf ffmpeg-dmo*


cd ffmpeg.svn
export CFLAGS="-mtune=native -march=native -mfpmath=sse -O4 -pipe"
fakeroot dpkg-buildpackage -uc -tc
cd ..


cp *.deb $APT_REPOSITORY
update-repository
ls -tr *.deb > ~/ffmpeg.pkg.list
ls -ltr

Wir laden die so erzeugte Liste in den Editor und entfernen alles, was nicht beim Bau von ffmpeg entstand:

vi ~/ffmpeg.pkg.list

Anschließend installieren wir alle erzeugten Pakete:

for i in $( < ~/ffmpeg.pkg.list ); do dpkg -i $i; done

Bau der xinelib-1.2

Der Autor der xinelib-1.2 hat ganze Arbeit geleistet und seiner Lib bereits ein debian-Verzeichnis spendiert. Trotzdem ist das Bauen der Xine-Pakete recht komplex insbesondere im VDR-Kontext. xinelib1.2 ist noch nicht offiziell in Debian integriert, deshalb ist etwas Handarbeit notwendig.
Das Ausfassen und Patchen der Quellen ist nur das erste Mal notwendig.

cd /usr/local/src/
hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2 xine-lib-1.2
wget http://www.jusst.de/vdpau/files/xine-lib-1.2/xine-lib-1.2-vdpau-r286.diff.bz2
bzip2 -d xine-lib-1.2-vdpau-r286.diff.bz2
wget http://durchflieger.dachsweb.de/vdpau-extensions/v11/xine-lib-1.2-vdpau-r286-extensions-v11.diff.gz
gunzip xine-lib-1.2-vdpau-r286-extensions-v11.diff.gz
cd xine-lib-1.2
patch -p1 < ../xine-lib-1.2-vdpau-r286.diff
patch -p1 < ../xine-lib-1.2-vdpau-r286-extensions-v11.diff

Vor dem Bau müssen noch die abhängigen Pakete für den Bau installiert werden. Mit

dpkg-checkbuilddeps

erhält man eine Liste der abhängigen Pakete. Die Ausgabe in eine Paketliste für apt-get umzuwandeln ist etwas lästig, deshalb habe ich die Liste hier aufgeführt:

cat > ~/xine.depends << EOF
libxcb-xv0-dev
libxcb-shm0-dev
libxcb-shape0-dev
libxinerama-dev
libxv-dev
libxvmc-dev
libxt-dev
libasound2-dev
libaa1-dev
libcaca-dev
libmodplug-dev
libjack-dev
libpulse-dev
libartsc0-dev
libmagick9-dev
libpng12-dev
libfreetype6-dev
libogg-dev
libvorbis-dev
libtheora-dev
libesd0-dev
libgnomevfs2-dev
liblircclient-dev
libdirectfb-dev
libgtk2.0-dev
libflac-dev
libsdl1.2-dev
libwavpack-dev
libsmbclient-dev
libspeex-dev
libmng-dev
libmad0-dev
libmpcdec-dev
libcdio-dev
libvcdinfo-dev
zlib1g-dev
w3m
xmlto
librsvg2-bin
EOF




apt-get install $( < ~/xine.depends )


dpkg-checkbuilddeps

sollte keine Pakete mehr aufführen. Damit VDPAU auch wirklich verwendet wird, ändern wir die Datei debian/rules – dort gibt es einen Bereich CONFIGURE_FLAGS := \ bei den darauf folgenden Zeilen fügen wir eine noch hinzu (aufpassen, dass kein Leerzeichen nach dem \ am Zeilenende kommt):

--with-vdpau \

Danach können wir endlich den Bau starten mit

fakeroot dpkg-buildpackage -uc -tc

Anschließend installieren wir die erstellten Pakete gleich und kopieren sie in unseren Paketpool:

cd /usr/local/src
for i in libxine*.deb; do dpkg -i $i; done
mv libxine*.deb $APT_REPOSITORY/pool
update-repository

VDR-Frontend für xinelib-1.2

Ein Blick in die control-Datei der neu gebauten xinelib-1.2 verrät uns, dass die lib als libxine2 firmiert. Also müssen wir unser Plugin daran anpassen. Für das Backend haben wir das xineliboutput-Plugin bereits übersetzt. Es hängt nur von libxine-dev ab, deshalb brauchen wir es jetzt nicht nochmal bauen.
Für den Bau des Frontends müssen wir allerdings die Steuerungsdatei patchen. Die Datei debian/rules laden wir in den Editor, suchen „xine:Depends“ und ersetzen libxine1 mit libxine2. Ferner ändern wir auch bei XINEPLUGINDIR das libxine1 gegen libxine2.
Die Frontends werden nur gebaut, wenn wir das Paket für vdr-1.6 bauen. Dann stimmt aber die Abhängigkeit der lib nicht, deshalb müssen wir selbst patchen. Wir sichern (nur beim ersten Mal!) die Steuerungsdatei doppelt:

cd /usr/local/src/vdr-plugin-xineliboutput-1.0.4+cvs20091215.2049
cp debian/control ~/control.xlop.backend
cp debian/control ~/control.xlop.frontend

Erste Sicherung ist dafür, falls wir das Backend nochmal bauen wollen/müssen. Die zweite laden wir jetzt in einen Editor und ändern bei der Beschreibung von libxineliboutput-sxfe in der Depends-Zeile vdr-plugin-xineliboutput (= ${binary:Version}) gegen vdrdevel-plugin-xineliboutput (>= ${binary:Version}) – gleiches machen wir für libxineliboutput-fbfe.
Anschließend ändern wir alle Vorkommnisse von xine1 in xine2:

:1,$s/xine1/xine2/g
:wq

Jetzt müssen noch die Installationsanweisungen angepasst werden:

cp debian/libxine1-xvdr.install debian/libxine2-xvdr.install

Danach aktivieren wir unsere Änderungen mit:

cp ~/control.xlop.frontend debian/control

Fehlt noch der Bau der Pakete:

PATCHVARIANT=multipatch fakeroot dpkg-buildpackage -uc -tc

und auch diese Pakete installieren wir umgehend

cd ..
dpkg -i libxine2-xvdr*.deb
dpkg -i libxineliboutput-sxfe*.deb
dpkg -i xineliboutput-sxfe*.deb

Zur Kontrolle schauen wir uns an, was alles von Xine installiert ist:

dpkg -l | grep xine

Es darf kein libxine1 in der Liste auftauchen! Sonst ist beim Bau was schief geganen. Die Ausgabe sollte eher so aussehen:

ii  libxine-dev                             1.2.0~hg-0
ii  libxine2                                1.2.0~hg-0
ii  libxine2-dbg                            1.2.0~hg-0
ii  libxine2-doc                            1.2.0~hg-0
ii  libxine2-xvdr                           1.0.4+cvs20091215.2049-2
ii  libxineliboutput-sxfe                   1.0.4+cvs20091215.2049-2
ii  libxinerama-dev                         2:1.0.3-2
ii  libxinerama1                            2:1.0.3-2
ii  vdrdevel-plugin-xineliboutput           1.0.4+cvs20091215.2049-2
ii  x11proto-xinerama-dev                   1.1.2-5
ii  xineliboutput-sxfe                      1.0.4+cvs20091215.2049-2

Falls doch ein libxine1 auftraucht, für jedes Paket, welches mit libxine1 anfängt ein apt-get purge absetzen und nochmal ab dem Bau der xinelib1.2 anfangen. Wer das Plugin erneut übersetzen muss/will, sollte vorher alle Dateien aus /usr/local/src die mit vdr-plugin-xine anfangen löschen.

Die eigenen Pakete testen

Bevor wir uns daran machen, das Produktivsystem hoch zu ziehen, können wir bereits am Entwicklungssystem ausprobieren, ob die gebauten Pakete funktionieren. Dafür sollte eine Budgetkarte im Entwicklungssystem vorhanden sein.
Wenn alle Pakete das erste Mal erstellt wurden, ist es nicht verkehrt, vor dem Test einmal kräftig durch zu booten
Dann prüfen wir, ob auch alle Pakete korrekt gebaut wurde und ihre Abhängigkeiten aufgelöst wurden:

cd
ls $APT_REPOSITORY/pool | grep -v linux | grep -v vdr-plugin > mystuff.list
cd $APT_REPOSITORY/pool
for i in $( < ~/mystuff.list ); do dpkg -i $i; done

Dabei sollte es keine Fehler über nicht aufgelöste Abhängigkeiten geben. Ein anschließendes

apt-get install

schafft Klarheit. Wenn jetzt irgendwelche Pakete installiert oder entfernt werden sollen, dann passen die Pakete noch nicht.

Gehen wir davon aus, dass alle Pakete passen ...

Dann schauen wir, ob die Budgetkarte erkannt wurde.

ls -l /dev/dvb/adapter0

Die Ausgabe sollte ungefär so aussehen:

crw-rw----+ 1 root video 212, 4 22. Dez 06:00 ca0
crw-rw----+ 1 root video 212, 0 22. Dez 06:00 demux0
crw-rw----+ 1 root video 212, 1 22. Dez 06:00 dvr0
crw-rw----+ 1 root video 212, 3 22. Dez 06:00 frontend0
crw-rw----+ 1 root video 212, 2 22. Dez 06:00 net0

Daraus folgt, dass der Benutzer vdr auf jeden Fall der Gruppe video zugeordnet werden muss. Wir nehmen audio und cdrom gleich mit dazu:

usermod -G video,audio,cdrom vdr

Falls der vdr bereits angestartet wurde (überprüfen mit ps -ef | grep vdr), beenden wir ihn (sonst wird die DVB-Karte blockiert und die Kanalsuche scheitert):

/etc/init.d/vdrdevel stop

Anschließend lassen wir uns eine Kanalliste[6] erzeugen. Vorher stellen wir sicher, dass wir uns in unserem Home-Verzeichnis befinden:

cd
w_scan -fs -s S19E2 -o 7 > channels.raw

oder z.B. für Kabel Deutschland:

w_scan -fc -c DE > channels.raw

Da kommen schnell ein paar Hundert Kanäle zusammen. Um auch hier den Überblick zu behalten, gibt es wieder ein kleines Skript, das Ordnung schafft (sortChannels.pl). Schließlich hat jeder einen anderen Geschmack, so auch bei der Reihenfolge der Sender. Dafür kann dem Skript eine Vorgabeliste mitgegeben werden – bitte nach eigenem Geschmack anpassen.

cat > channels.preset << EOF
Das Erste
ZDF
SWR Fernsehen BW
ZDFtheaterkanal
SAT 1
RTL Television
ProSieben
kabel eins
3sat
arte
...
BAYERN 4 KLASSIK
hr2
WDR 2 Klassik
SWR 3
DELUXE LOUNGE
DELUXE RADIO
FREQUENCE JAZZ
Swiss Jazz
sunshine live
EOF

Bei der Sortierung wird jedem Sender aus der Vorgabeliste die Zeilennummer als Wunschkanal zugeordnet. Ansonsten sortiert das Skript nach folgender Reihenfolge:
HD =>> TV =>> Radio =>> TV verschlüsselt =>> Radio verschlüsselt
Die Sender aus der Vorgabeliste bleiben in ihrer Kategorie, werden dort aber entsprechend bevorzugt eingeordnet.

vi /usr/local/bin/sortChannels.pl
i

Jetzt wieder den Inhalt in den Editor übernehmen und mit :wq speichern.

#!/usr/bin/perl
# This script takes a channels.conf generated from w_scan and sorts 
# the channels. A preset file with channel names may be specified to
# override sort order.
# Sections: HD -> TV -> Radio -> TV crypted -> Radio crypted
# Channels of each section will be sorted by name. Entries from preset
# will be sorted respecting above sections, but overriding the sort order
# by name.
#
use strict;
use IO::File;


my $debug = 0;
my $presetFN = '/etc/vdr/channels.preset';
my (%preset, @sorted, @channels);




sub loadPreset {
   my $psfn = shift;
   my $fh = new IO::File;
   my $line;
   my $i=1;


   if ($fh->open("< $psfn")) {
      while ($line = <$fh>) {
         chomp $line;
         print('gonna process >'.$line."<\n") if $debug;

         $preset{$line} = $i++;
      }
      $fh->close();
   }
}




sub fetchChannels {
   my $cfn = shift;
   my $fh = new IO::File;
   my $i=0;

   if ($fh->open("< $cfn")) {
      while (my $line = <$fh>) {
         chomp $line;
         my @parts = split(/:/, $line);
         my ($name, $bouquet) = split(/;/, $parts[0], 2);
         my $crypted = 'Y';
         my $radio = 'N';
         my $hd = 'N';
         my $level = 999;


         $crypted = 'N' if $parts[8] == 0;
         $radio = 'Y' if $parts[5] == 0;
         $hd = 'Y' if $name =~ /HD/;
         $level = $preset{$name} if defined($preset{$name});
         $level = 0 if $name =~ /HD/;
         my $entry = { 'name'    => $name,
                       'bouquet' => $bouquet,
                       'hd'      => $hd,
                       'crypted' => $crypted,
                       'level'   => $level,
                       'radio'   => $radio,
                       'line'    => $line };
         push(@channels, $entry);
      }
      $fh->close();
   }
}


sub tellChannels {
   my $i=0;


   for my $cEntry (@sorted) {
      if ($debug) {
         print('chn ('.$i++.') - name: '.$cEntry->{'name'}
               .', bouquet: '.$cEntry->{'bouquet'}
               .', crypted: '.$cEntry->{'crypted'}
               .', hd: '.$cEntry->{'hd'}
               .', radio: '.$cEntry->{'radio'}
               ."\n");
      } else {
         print($cEntry->{'line'}."\n");
      }
   }
}


sub byKeys {
   $a->{'crypted'} cmp $b->{'crypted'} ||
   $a->{'radio'} cmp $b->{'radio'} ||
   $b->{'hd'} cmp $a->{'hd'} ||
   $a->{'level'} <=> $b->{'level'} ||
   uc($a->{'name'}) cmp uc($b->{'name'});
}


my $channelFile = shift;
die 'please give me a channels.conf file to sort!'."\n" if $channelFile =~ /^\s*$/;
print('have to sort '.$channelFile."\n") if $debug;
my $tmp = shift || $presetFN;
print('load preset from '.$tmp."\n") if $debug;
loadPreset($tmp);
fetchChannels($channelFile);
@sorted = sort byKeys @channels;
tellChannels();

Auch dieses Script wird ausführbar gemacht mit

chmod +x /usr/local/bin/sortChannels.pl

Wer die Sortier-Reihenfolge ändern will, sollte sich die Funktion byKeys anschauen (Zeile 85ff) – schon allein durch Vertauschen der Zeilen kann die Sortierung verändert werden.
Wer mag, kann die preset-Datei in /etc/vdr speichern. Dann wird sie automatisch verwendet. Ansonsten kann die preset-Datei auch als Parameter angegeben werden:

sortChannels.pl channels.raw channels.preset > channels.conf
less channels.conf

Wenn wir mit der Sichtprüfung einverstanden sind, kann die Datei dem VDR übergeben werden. Dazu prüfen wir zuerst, welche Datei vom VDR verwendet wird:

ls -l /etc/vdrdevel/channels.conf

liefert bei mir: /etc/vdrdevel/channels.conf -> /var/lib/vdrdevel/channels.conf

cp channels.conf /var/lib/vdrdevel

Jetzt öffnen wir eine zweite Befehlszeile zum Entwicklungssystem und starten dort

tail -f /var/log/syslog

denn der VDR, wie auch das xinelibout-Frontend schreiben ihre Meldungen in den syslog. So gewapnet starten wir den vdr mit:

/etc/init.d/vdrdevel start

Im syslog sollten wir jetzt sehen, dass alle Plugins geladen werden. Dort erfahren wir auch, dass das xineliboutput-Plugin 127.0.0.1 als Adresse verwendet und über den Port 37890 erreichbar ist.
Dann kommt ein Fehler, dass /dev/lircd nicht existiert – Kunststück, wo wir das noch garnicht installiert haben. Ansonsten sehen die Ausgaben nicht schlecht aus, sodass wir uns dem Frontend widmen können.
Wir erstellen einen eigenen XServer nur für den VDR:

cd /etc/init.d
wget http://www.gerloni.net/LinuxVDR/LinuxVDRconfig/etc/init.d/X4VDR
chmod +x /
update-rc.d X4VDR start 19 2 3 4 5 . stop 21 0 1 6 .


cat > /etc/vdrdevel/plugins/plugin.xineliboutput.conf << EOF
# Command line parameters for vdrdevel-plugin-xineliboutput
#
# For more details see:
#   - /usr/share/doc/vdrdevel-plugin-xineliboutput/README.Debian
#   - vdrdevel --help -Pxineliboutput
#   - /usr/share/doc/vdrdevel-plugin-xineliboutput/README
#
--local=sxfe
--fullscreen
--display=:1.0
--remote=127.0.0.1:37890
EOF

Die Datei /var/lib/vdrdevel/setup.conf wird um folgende Einträge erweitert:

cat >> /var/lib/vdrdevel/setup.conf << EOF
EOF

Für rudimentäre Tastatur-Unterstützund beim Frontend erzeugen wir uns eine remote.conf:

cat > /var/lib/vdrdevel/remote.conf << EOF
KBD.Up         00000000001B5B41
KBD.Down       00000000001B5B42
KBD.Menu       000000000000006D
KBD.Ok         000000000000000D
KBD.Back       000000000000007F
KBD.Left       00000000001B5B44
KBD.Right      00000000001B5B43
KBD.Red        000000001B5B5B41
KBD.Green      000000001B5B5B42
KBD.Yellow     000000001B5B5B43
KBD.Blue       000000001B5B5B44
KBD.0          0000000000000030
KBD.1          0000000000000031
KBD.2          0000000000000032
KBD.3          0000000000000033
KBD.4          0000000000000034
KBD.5          0000000000000035
KBD.6          0000000000000036
KBD.7          0000000000000037
KBD.8          0000000000000038
KBD.9          0000000000000039
KBD.Info       0000000000000069
KBD.FastFwd    0000001B5B31377E
KBD.FastRew    000000001B5B5B45
KBD.Power      0000000000000070
KBD.Volume+    0000001B5B32347E
KBD.Volume-    0000001B5B32337E
KBD.Mute       0000001B5B32317E
KBD.User7      0000001B5B31387E
KBD.User8      0000001B5B31397E
KBD.User9      0000001B5B32307E
XKeySym.Up         Up
XKeySym.Down       Down
XKeySym.Menu       m
XKeySym.Ok         Return
XKeySym.Back       BackSpace
XKeySym.Left       Left
XKeySym.Right      Right
XKeySym.Red        F1
XKeySym.Green      F2
XKeySym.Yellow     F3
XKeySym.Blue       F4
XKeySym.0          0
XKeySym.1          1
XKeySym.2          2
XKeySym.3          3
XKeySym.4          4
XKeySym.5          5
XKeySym.6          6
XKeySym.7          7
XKeySym.8          8
XKeySym.9          9
XKeySym.Info       i
XKeySym.Pause      space
XKeySym.FastFwd    F6
XKeySym.FastRew    F5
XKeySym.Power      p
XKeySym.Volume+    F12
XKeySym.Volume-    F11
XKeySym.Mute       F10
XKeySym.User7      F7
XKeySym.User8      F8
XKeySym.User9      F9
EOF

Wenn wir jetzt den VDR stoppen und neu starten, sollte auf Konsole Nr. 8 das Bild erscheinen.

/etc/init.d/vdrdevel stop
/etc/init.d/vdrdevel start

Wenn wir mit dem Ergebnis zufrieden sind, können wir uns an die Einrichtung des Produktivsystems machen.

Ein Vorteil dürfte bereits im Entwicklungssystem klar geworden sein:
Wir haben außerhalb von /usr/local keine Dateien im System, die nicht über das Debian-Paktesystem installiert wurden und somit jederzeit wieder entfernt werden können.
Einzige Ausnahme ist der Nvidia-Kernel, aber damit kann ich gut leben. Der muss eben nach jeder Kernelaktualisierung erneut installiert werden. Weiterhin haben wir ein System, in dem es NUR vdrdevel-Pakete gibt. Kein Mischmasch oder sonstige Unsicherheiten. Ich denke, das rechtfertigt den Mehraufwand allemal.

Produktivsystem einrichten

Im Augenblick kämpfe ich noch mit der Einrichtung/Konfiguration des VDR. Sobald die in trockenen Tüchern ist, werden die Abschnitte ausgefüllt.

eigenes Repository einbinden

Installation

Rechner mit VDR-Backend (DVB-Karte, Festplatte für Aufnahmen)

Rechner mit VDR-Frontend (VDPAU)

XServer aktivieren

Weiterführender Stoff zum Lesen

• Eine kompakte Beschreibung zum Aufsetzen eines Ftp-Servers gibt es unter http://www.pc-howto.com/server/ftp-server-mit-vsftp
• Die offizielle Beschreibung zum Einrichten eines Ftp-Servers gibt es hier: http://debiananwenderhandbuch.de/ftpserver.html
• Die Einrichtung eines Webservers wird beschrieben unter http://debiananwenderhandbuch.de/server.html#apache
• Hintergrundinformationen zu VDPAU mit umfangreichen Tips http://wbreu.htpc-forum.de/index.php
• allgemeine Informationen rund um den VDR http://www.vdr-wiki.de/wiki
• Kanäle suchen lassen: http://www.vdr-wiki.de/wiki/index.php/W_scan