Aufsetzen eines schlanken HD-VDRs unter Debian mit passender Entwicklungsumgebung

... oder auch: immer schön sauber bleiben

Vorwort

Wer Debian einsetzt, tut dies, weil er das Paketsystem und die Updatepolitik für das Beste hält, was es unter Linux gibt. Warum also beim VDR darauf verzichten und das System durch selbstübersetzte Pakete verunreinigen?
Deshalb habe ich nach einem Weg gesucht, selbst Pakete übersetzen zu können, ohne die geniale Paketverwaltung von Debian umgehen zu müssen. Ganz klar – ein Entwicklungssystem braucht nur, wer auch am VDR entwickeln will – also z.B. ein Plugin bauen oder anpassen. Wer das nicht vorhat, braucht überhaupt nichts zu übersetzen.
Mit etwas Sinn für Ordnung lässt sich so ein Entwicklungssystem relativ einfach aufsetzen und warten. Andererseits ist der Paketbau unter Debian alles andere als trivial. Deshalb habe ich an einigen Stellen Zugeständnisse an die 2-Gleisigkeit des VDR, sowie an mein fehlendes Wissen gemacht.
Diese Beschreibung soll dabei helfen, ein sauberes Entwicklungssystem und ein schlankes Produktivsystem synchron pflegen zu können.
Sie ist eine Mischung aus Kilroys Howto, Auszügen aus dem Wiki, den Beschreibungen von wbreu, Tips von hummingbird_de und natürlich eigenen Erfahrungen - das Ganze ausprobiert und in die richtige Reihenfolge gebracht. Selbstverständlich bedanke ich mich auch bei allen, die geholfen haben und die ich jetzt vergaß zu erwähnen!

Hinweise zu Hintergrundinformationen finden sich am Ende der Beschreibung.

Wer allerdings den Computer-Desktop auf den Fernsehr bringen will, wird vermutlich von dieser Beschriebung enttäuscht. Hier geht es - NUR - darum, HD-Fernsehen und HD-Aufnahmen zu ermöglichen. Der Rest soll am Computer bleiben.
Viele Miniboards haben keinen Anschluss mehr für Floppy oder PATA-Laufwerke – da bietet sich ein USB-Stick als Installationsmedium geradezu an. Mit unetbootin (http://unetbootin.sourceforge.net) lässt sich ein bootbarer USB-Stick einrichten. Bei Debian stable gibt es unetbootin noch nicht als Paket, aber es lässt sich recht einfach bauen: http://sourceforge.net/apps/trac/unetbootin/wiki/compile
Wer viel mit USB-Stick Installationen experimentiert, dem wird es sicher auch mal passieren, dass grub auf dem Stick anstatt auf der Festplatte installiert wird. Danach wird es unentspannt mit dem Stick zu booten – denn er wird vom BIOS bereits als Festplatte erkannt und eingebunden. Da hilft nur ein beherztes



code: 1: mkdosfs -I /dev/sdx

(/dev/sdx gegen das Device des Sticks austauschen). Danach wird der Stick wieder als Bootmedium akzeptiert.

Noch ein Hinweis zu den Skripten, die nebenbei erzeugt werden. Wenn in einem Skript Variablen verwendet werden (Text bei dem $ der erste Buchstabe ist), werden die gelöscht oder ersetzt, wenn per copy/paste in der Befehlszeile gearbeitet wird.

Wird statt dessen der vi mit dem Dateinamen geöffnet und mit i der Eingabemodus aktiviert, kann das Skript per copy/paste per Umschalt+Einfügetaste übernommen werden.

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.

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.



code: 1: 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.

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:



code: 1: 2: 3: 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):



code: 1: 2: 3: 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.



code: 1: 2: 3: 4: 5: 6: 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



code: 1: . ./.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:



code: 1: 2: 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



code: 1: apt-get update && apt-get dist-upgrade

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



code: 1: upgrade-from-grub-legacy

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

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.

zuerst die Gruppe vdr anlegen:



code: 1: addgroup -system vdr


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



code: 1: adduser -system -ingroup vdr vdr

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.



code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 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 )

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.



code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 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

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



code: 1: 2: 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:



code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 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 ...



code: 1: 2: 3: 4: 5: 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 ...



code: 1: 2: 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



code: 1: 2: 3: 4: 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 ...



code: 1: 2: 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.

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.

code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 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 )

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

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



code: 1: 2: 3: 4: 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:



code: 1: 2: 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“.



code: 1: 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:



code: 1: export CONCURRENCY_LEVEL=4


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



code: 1: 2: 3: cat >> /etc/profile << EOF export CONCURRENCY_LEVEL=4 EOF

Den Kernelbau starten wir mit:



code: 1: make-kpkg --append-to-version -vdr --initrd kernel_image kernel_headers


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



code: 1: 2: 3: 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



code: 1: 2: update-initramfs -ck 2.6.32.2-vdr update-grub

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

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:



code: 1: 2: mkdir -p /srv/debian/dists/sid/main/binary-amd64 mkdir -p /srv/debian/pool

Fehlt noch eine Beschreibung für unsere Paketquelle:



code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 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:



code: 1: 2: 3: 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:



code: 1: 2: vi /usr/local/bin/update-repository i


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



code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: #!/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



code: 1: chmod +x /usr/local/bin/update-repository

Jetzt können wir es gleich ausprobieren:



code: 1: 2: 3: 4: 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.

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



code: 1: apt-get purge firmware-linux-free

Dann bauen wir die neuen Treiber mit:



code: 1: 2: 3: 4: 5: 6: 7: 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:



code: 1: 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:



code: 1: 2: 3: cp *.deb $APT_REPOSITORY/pool update-repository dpkg -i dvb-s2-liplianin*.deb

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:



code: 1: 2: 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.

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.



code: 1: 2: 3: 4: 5: 6: 7: 8: 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:



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

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



code: 1: 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:



code: 1: 2: 3: 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:



code: 1: 2: vi /usr/local/bin/buildVDR i

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



code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: #!/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:



code: 1: 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:



code: 1: 2: 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.

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:



code: 1: 2: 3: 4: 5: 6: 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:



code: 1: 2: 3: checkinstall make install cp *.deb $APT_REPOSITORY/pool update-repository

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

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



code: 1: apt-get install linux-headers-2.6.32.2-trunk-amd64

Kernelversion ggf. an den verwendeten Kernel anpassen.

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



code: 1: 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):



code: 1: 2: 3: 4: 5: 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:



code: 1: 2: 3: grep NVIDIA /var/log/syslog ... NVRM: loading NVIDIA UNIX x86_64 Kernel Module 190.53 Wed Dec 9 15:29:46 PST 2009

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



code: 1: 2: 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:



code: 1: 2: 3: 4: 5: 6: cat >> /etc/X11/xorg.conf << EOF Section "Extensions" Option "Composite" "Disable" EndSection EOF




code: 1: 2: 3: cat >> /etc/profile << EOF export DISPLAY=':0.0' EOF




code: 1: 2: 3: cat >> /home/vdr/.xhosts << EOF 127.0.0.1 EOF

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

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.



code: 1: 2: 3: 4: 5: 6: 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



code: 1: 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.

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:



code: 1: 2: 3: 4: 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.

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



code: 1: 2: 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:



code: 1: 2: 3: 4: 5: 6: 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:



code: 1: --enable-asm und --enable-pic

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



code: 1: 2: 3: 4: 5: 6: 7: 8: 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:



code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 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:



code: 1: vi ~/ffmpeg.pkg.list


Anschließend installieren wir alle erzeugten Pakete:



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

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.



code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 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



code: 1: 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:



code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 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):



code: 1: --with-vdpau \

Danach können wir endlich den Bau starten mit



code: 1: fakeroot dpkg-buildpackage -uc -tc

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



code: 1: 2: 3: 4: cd /usr/local/src for i in libxine*.deb; do dpkg -i $i; done mv libxine*.deb $APT_REPOSITORY/pool update-repository

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 epends“ 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:



code: 1: 2: 3: 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:



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

Jetzt müssen noch die Installationsanweisungen angepasst werden:



code: 1: cp debian/libxine1-xvdr.install debian/libxine2-xvdr.install

Danach aktivieren wir unsere Änderungen mit:



code: 1: cp ~/control.xlop.frontend debian/control

Fehlt noch der Bau der Pakete:



code: 1: PATCHVARIANT=multipatch fakeroot dpkg-buildpackage -uc -tc

und auch diese Pakete installieren wir umgehend



code: 1: 2: 3: 4: 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:



code: 1: 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:



code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 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.

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:



code: 1: 2: 3: 4: 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



code: 1: 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.



code: 1: ls -l /dev/dvb/adapter0

Die Ausgabe sollte ungefär so aussehen:



code: 1: 2: 3: 4: 5: 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:



code: 1: 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):



code: 1: /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:



code: 1: 2: cd w_scan -fs -s S19E2 -o 7 > channels.raw

oder z.B. für Kabel Deutschland:



code: 1: 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.



code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 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.



code: 1: 2: vi /usr/local/bin/sortChannels.pl i

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



code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: 54: 55: 56: 57: 58: 59: 60: 61: 62: 63: 64: 65: 66: 67: 68: 69: 70: 71: 72: 73: 74: 75: 76: 77: 78: 79: 80: 81: 82: 83: 84: 85: 86: 87: 88: 89: 90: 91: 92: 93: 94: 95: 96: 97: 98: 99: 100: 101: 102: #!/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



code: 1: 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:



code: 1: 2: 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:



code: 1: ls -l /etc/vdrdevel/channels.conf

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



code: 1: cp channels.conf /var/lib/vdrdevel

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



code: 1: 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:



code: 1: /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:



code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 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:



code: 1: 2: cat >> /var/lib/vdrdevel/setup.conf << EOF EOF

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



code: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: 54: 55: 56: 57: 58: 59: 60: 61: 62: 63: 64: 65: 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.



code: 1: 2: /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.

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

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

This post has been edited 1 time(s), it was last edited by geronimo: 27.12.2009 15:49.

This post has been edited 1 time(s), it was last edited by wilderigel: 29.12.2009 23:03.