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.


  • 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.


    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.


  • 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:


    Code
    1. export LS_OPTIONS='--color=auto'
    2. eval "`dircolors`"
    3. 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. alias ll='ls $LS_OPTIONS -l'
    2. alias la='ls $LS_OPTIONS -la'
    3. 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. alias c='clear'
    2. alias ac='apt-cache -n search'
    3. alias ai='apt-get install'
    4. alias ii='dpkg -l | grep -i'
    5. alias pi='apt-cache show'
    6. 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. deb http://ftp.de.debian.org/debian/ sid main non-free contrib
    2. 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.


  • 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:


    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



  • 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.




  • 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.




  • Paketrepository um e-tobi und multimedia erweitern

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


    Code
    1. wget --quiet http://e-tobi.net/vdr-experimental/pool-lenny/binary/base/e-tobi-keyring_2008.03.08_all.deb
    2. 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:


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


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

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


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

    Debian-multimedia.org einrichten


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

    aufräumen ...


    Code
    1. rm *.deb
    2. 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



    • 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.


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


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


      Code
      1. cp /boot/config-2.6.32-trunk-amd64 .config
      2. 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. cat >> /etc/profile << EOF
      2. export CONCURRENCY_LEVEL=4
      3. 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. cd /usr/src
      2. dpkg -i linux-image-2.6.32.2-vdr*.deb
      3. 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. update-initramfs -ck 2.6.32.2-vdr
      2. 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:


      Code
      1. mkdir -p /srv/debian/dists/sid/main/binary-amd64
      2. mkdir -p /srv/debian/pool

      Fehlt noch eine Beschreibung für unsere Paketquelle:


      Code
      1. cat > /srv/debian/dists/sid/Release << EOF
      2. Origin: myself
      3. Label: the freshest sauces around
      4. Suite: unstable
      5. Codename: sid
      6. Date: Fri, 19 Dec 2009 06:00:00 UTC
      7. Archtectures: amd64
      8. Components: main
      9. Description: my own vdr packages – not released
      10. EOF

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


      Code
      1. cat >> /etc/profile << EOF
      2. export APT_REPOSITORY='/srv/debian'
      3. EOF

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


      Code
      1. vi /usr/local/bin/update-repository
      2. i


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



      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. export APT_REPOSITORY='/srv/debian'
      2. cd /usr/src
      3. mv linux-*.deb $APT_REPOSITORY/pool
      4. 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:


      Code
      1. apt-get purge firmware-linux-free

      Dann bauen wir die neuen Treiber mit:


      Code
      1. cd /usr/local/src
      2. hg clone http://mercurial.intuxication.org/hg/s2-liplianin/
      3. cd s2-liplianin
      4. cd linux/include/linux
      5. ln -s /usr/src/linux-headers-`uname -r`/include/linux/compiler.h .
      6. cd ../../..
      7. 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. cp *.deb $APT_REPOSITORY/pool
      2. update-repository
      3. 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:


      Code
      1. cd /usr/local/src
      2. 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.


      Code
      1. cat > backendPlugins.list << EOF
      2. vdr-plugin-dvd
      3. vdr-plugin-dvdselect
      4. vdr-plugin-epgsearch
      5. vdr-plugin-markad
      6. vdr-plugin-skinelchi
      7. vdr-plugin-xineliboutput
      8. EOF

      Damit können wir die Quelltexte ausfassen:


      Code
      1. cd /usr/local/src
      2. 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. apt-get source make-special-vdr
      2. cp make-special-vdr-1.4/make-special-vdr /usr/local/bin
      3. 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. vi /usr/local/bin/buildVDR
      2. i

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


      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. buildVDR
      2. 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:


      Code
      1. cd /usr/local/src
      2. wget http://wirbel.htpc-forum.de/w_scan/w_scan-20091118.tar.bz2
      3. tar -jxf w_scan-20091118.tar.bz2
      4. cd w_scan-20091118
      5. ./configure
      6. make

      Danach bauen wir uns wieder ein Päckchen:


      Code
      1. checkinstall make install
      2. cp *.deb $APT_REPOSITORY/pool
      3. 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


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


      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. cd /usr/local/src
      2. mkdir nvidia
      3. cd nvidia
      4. wget ftp://download.nvidia.com/XFree86/Linux-x86_64/190.53/NVIDIA-Linux-x86_64-190.53-pkg2.run
      5. 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. grep NVIDIA /var/log/syslog
      2. ... 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:


      Code
      1. NODM_ENABLED=true
      2. 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. cat >> /etc/X11/xorg.conf << EOF
      2. Section "Extensions"
      3. Option "Composite" "Disable"
      4. EndSection
      5. EOF


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


      Code
      1. cat >> /home/vdr/.xhosts << EOF
      2. 127.0.0.1
      3. 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.


      Code
      1. cd /usr/local/src
      2. wget http://www.cs.rug.nl/~wladimir/vdpinfo/vdpinfo-0.0.5.tar.gz
      3. tar -zxf vdpinfo-0.0.5.tar.gz
      4. cd vdpinfo
      5. make
      6. 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.


    • 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:


      Code
      1. cd /usr/local/src/vdr-plugin-xineliboutput-1.0.4+cvs20091215.2049
      2. PATCHVARIANT=multipatch fakeroot dpkg-buildpackage -b -uc -tc
      3. cp xine*.deb $APT_REPOSITORY/pool
      4. 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


      Code
      1. cd /usr/local/src
      2. 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. apt-get source libx264
      2. rm x264*
      3. git clone git://git.videolan.org/x264.git
      4. cp -a x264-0.svn20091125/debian x264/debian
      5. rm -rf x264-0.svn*
      6. 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. export CFLAGS=“-mtune=native -march=native -mfpmath=sse -O4 -pipe"
      2. fakeroot dpkg-buildpackage -uc -tc
      3. cd ..
      4. dpkg -i libx264-dev_0.svn20091125-0.1_amd64.deb
      5. dpkg -i libx264-79_0.svn20091125-0.1_amd64.deb
      6. dpkg -i x264_0.svn20091125-0.1_amd64.deb
      7. mv {lib,}x264*.deb $APT_REPOSITORY/pool
      8. update-repository

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


      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



    • 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.


      Code
      1. cd /usr/local/src/
      2. hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2 xine-lib-1.2
      3. wget http://www.jusst.de/vdpau/files/xine-lib-1.2/xine-lib-1.2-vdpau-r286.diff.bz2
      4. bzip2 -d xine-lib-1.2-vdpau-r286.diff.bz2
      5. wget http://durchflieger.dachsweb.de/vdpau-extensions/v11/xine-lib-1.2-vdpau-r286-extensions-v11.diff.gz
      6. gunzip xine-lib-1.2-vdpau-r286-extensions-v11.diff.gz
      7. cd xine-lib-1.2
      8. patch -p1 < ../xine-lib-1.2-vdpau-r286.diff
      9. 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:


      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. cd /usr/local/src
      2. for i in libxine*.deb; do dpkg -i $i; done
      3. mv libxine*.deb $APT_REPOSITORY/pool
      4. 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:


      Code
      1. cd /usr/local/src/vdr-plugin-xineliboutput-1.0.4+cvs20091215.2049
      2. cp debian/control ~/control.xlop.backend
      3. 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. :1,$s/xine1/xine2/g
      2. :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. cd ..
      2. dpkg -i libxine2-xvdr*.deb
      3. dpkg -i libxineliboutput-sxfe*.deb
      4. 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:


      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:


      Code
      1. cd
      2. ls $APT_REPOSITORY/pool | grep -v linux | grep -v vdr-plugin > mystuff.list
      3. cd $APT_REPOSITORY/pool
      4. 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. crw-rw----+ 1 root video 212, 4 22. Dez 06:00 ca0
      2. crw-rw----+ 1 root video 212, 0 22. Dez 06:00 demux0
      3. crw-rw----+ 1 root video 212, 1 22. Dez 06:00 dvr0
      4. crw-rw----+ 1 root video 212, 3 22. Dez 06:00 frontend0
      5. 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. cd
      2. 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.


      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. vi /usr/local/bin/sortChannels.pl
      2. i

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


      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. sortChannels.pl channels.raw channels.preset > channels.conf
      2. 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:


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


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

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


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


      Code
      1. /etc/init.d/vdrdevel stop
      2. /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

    • Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

      The post was edited 1 time, last by geronimo ().

    • Quote

      Aufsetzen eines schlanken HD-VDRs unter Debian mit passender Entwicklungsumgebung


      PUUH


      Das sieht nach einer Menge Holz aus. Aber ich spiele auch schon seit einiger Zeit mit dem Gedanken, meinem VDR HDTV beizubringen. Da ich dafür aber eine weitere Test-Kiste aufsetzen müsste (O-Ton der Regierung: "Wieso steht hier denn schon wieder ein neuer Computer im Weg herum?" :unsch ), wozu mir derzeit etwas die Kraft fehlt, werde ich gespannt Dein HOWTO verfolgen und auf das ultimative


      Code
      1. aptitude install vdrHD

      warten. :lachen2


      Auf jeden Fall schon mal Danke für die Mühe! :prost2

    • Hallo kilroy,


      schön von Dir zu lesen!


      Du hast Recht, das war ne Menge Holz, aber nur weil ich normalerweise, außer apt-get install, nix mit dem Betriebssystem am Hut habe. Die Zeiten, in denen ich selbst den Compiler angeschmissen habe, sind doch sehr lange her und wenn man die Pakete richtig bauen wollte, wäre sicher noch viel mehr Aufwand nötig.


      Mit dem Warten hast Du sicher Recht.


      Nicht weil ich den Weg gehen will, aber ich bin doch sehr enttäuscht von ION und VDPAU und so.
      Insbesondere die seltsamen Bildstörungen bei AnixeHD (ich denke mal, dass die Vollbildmaterial senden) haben mich völlig frustriert.
      Als ich jetzt erfuhr, dass das Ganze damit zusammenhängt, dass ich nen falschen Monitor habe ...


      Also auf meinem Desktop (Debian etch, alles Standard) kann ich mkv-Dateien abspielen und habe perfektes Bild und Ton am gleichen Monitor (nur friert das Bild gelegentlich ein) - es muss also möglich sein.
      Da ich eine der ältesten core2Duo am Desktop habe, denke ich, dass ein CPU-Upgrade mehr bringen würde, als der ganze VDPAU-Hype - und wäre zudem wesentlich leichter zu pflegen, da ein funktionierendes System nicht von tausenenden aufeinander abgestimmter Konfigurationsparameter abhängig ist. Stand heute kann man sich übers OSD (durch Verändern einiger Paramter von xineliboutput-Plugin) den VDR nicht nur unbedienbar machen, sondern es kann passieren, dass er danach nur noch abstürzt. Wer sich dann nicht mit den Internas auskennt und weiß, wo er hinlangen muss, um das System wieder zurückzusetzen - hat verloren. Das entspricht nicht meiner Vorstellung von Benutzerfreundlichkeit.


      Also für mich ist VDPAU damit vergleichbar, als wenn ein Pilot den Eurofighter manuell fliegen wollte - das ist schlicht unmöglich, da das Flugzeug keinen konventionellen aerodynamischen Regeln entspricht. Nur das computerbasierte, hochkomplexe Steuerungs- und Regelungssystem ermöglicht es dem Menschen so ein Flugzeug zu "beherrschen".


      Das heißt, ich werde mich eher mal in die Richtung CPU-Upgrade orientieren, bzw. es zumindest ausprobieren. VDPAU ist - für mich - ein Irrweg.


      Die entsprechende Entwicklungsumgebung wird dann natürlich viel einfacher, weil "nur" der VDR, bzw. einzelne Plugins übersetzt werden müssten.
      Dem Paketprinzip von Debian werde ich treu bleiben :)


      Gruß Geronimo

      Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

    • geronimo ,


      Was für eine Wohltat! Seit Jahren unter Gentoo und Ubuntu arbeitend habe ich eine ganze Reihe vdr-Distris ausprobiert, und war jedes mal frustriert. Da wird ein _config Verzeichnis in den Verzeichnisbaum eingepflanzt, obwohl sowas doch zumindest in ein /opt/xyz... gehört hätte. Da ist kein schlichtes "emerge emacs" möglich, obwohl das unter Gentoo doch eigentlich vorgesehen ist. Da geht unter den Debian-basierten Systemen kein normales vdr-update via apt, weil man besser den ganzen vdr neu installieren sollte, usw. usw.


      Ich habe mir Deinen Beitrag noch nicht ganz einverleibt. Aber ich habe schon bemerkt, dass er mir aus der Seele spricht. Es wäre doch eine tolle Sache, wenn die vdr-Installationen sich nach dem Linux FHS richten würde, und auch die diversen Konfigurationsorgien nicht über dutzendfach querverlinkte Verzeichnisse organisiert wäre.


      So sehe ich aktuell ein '/file' directory, verlinkt auf 'mnt/data/file'. In 'mnt/' findet sich ein link 'hda5/', der ebenfalls auf 'data' zeigt. In 'hda5' finde ich ein 'pictures' Verzeichnis, in welchem es einen MEDIA Eintrag gibt, der aber wiederum ein Link auf '/media' ist, und einen weiteren Eintrag 'DISC', der wiederum ein Link auf '/mnt/cdrom' ist, usw. usw.


      Mir kommt das -vorsichtig ausgedrückt- alles sehr "gewachsen" vor, und zwar im Sinne von 'nicht designed'. So sind Probleme programmiert, und für den Neueinsteiger ist das Ganze kaum durchschaubar.


      Deshalb werde ich Deinen Beitrag in einer ruhigen Stunde mal durcharbeiten. Mein Wunsch: ein schlankes Debian-System nach FHS mit der Möglichkeit normaler apt und dpkg Anwendung zur Installation und Pflege eines nach Linux- und Debian-Standards sauber installierten vdr.


      Besten Dank!

    • Hallo emax,


      ich danke Dir für Deine Zeilen und freue mich, dass ich nicht der Einzige bin, dem es nicht egal ist, wo eine Datei oder ein Verzeichnis liegt ;)


      Gruß Geronimo

      Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

    • Hallo geronimo,


      vielen Dank für die Anleitung.


      Ich habe mich viele Stunden abgemüht eine saubere VDR-Installation mit .deb-Paketen hinzubekommen. Leider hatte ich damit keinen Erfolg. Deshalb habe ich vor 3 Tagen mit Wikis Anleitung ([Howto] Ubuntu 9.10 + vdr + xbmc) installiert.


      Es funktioniert nun. Leider gibt es immer wieder einmal Abstürze oder Hänger (z. B. wenn bei Aufnahmen schnell vor- und zurückgespult wird). Ich bin mir nun nicht ganz im klaren, ob das an meiner etwas tradierten Hardware (Pentium IV/768 MB RAM/nvidia GeForce 8400 PCI) liegt oder an meiner Installation.


      Deshalb meine Frage: Wie stabil ist denn Dein Ergebnis? Kommen Abstürze oder freezes vor? Wenn das System damit stabiler würde wäre der WAF bei weitem höher.


      Danke!



      goldfisch

    • Quote

      Original von goldfisch
      ... (z. B. wenn bei Aufnahmen schnell vor- und zurückgespult wird) ...


      goldfisch


      Das Problem habe ich bei HD Aufnahmen im TS Format mit den verschiedensten Installationsarten, das wird sich bestimmt mit nächsten Versionen klären. Bitte vergiß nicht, die Versionen 1.7.x sind nicht umsonst noch als Entwicklerversionen gekennzeichnet.


      Wenn Du stable im Sinne von "rock-solid" haben willst, mußt Du IMHO irgendeine Installation mit 1.6.0 oder gar 1.4.7 wählen.


      Kind regards
      hummingbird_de

      HowTo: APT pinning

    • goldfisch


      zu 1.: Generell nein. Aber "gda" hat ein Repository mit einem auf HD gepatchten 1.6.0er für Jaunty im Angebot. Ich hoffe er hat es noch nicht vom Server genommen.
      zu 2. IMHO gibt es das, ich meine das paket heißt, xineliboutput-sxfe. Ist aber m.E. nicht HD-fähig.


      Nun machen wir aber Schluß hier, das hat alles nichts mit geronimo's Ursprungsthema zu tun.


      Kind regards
      hummingbird_de

      HowTo: APT pinning

      The post was edited 1 time, last by fnu ().

    • Quote

      Original von hummingbird_de
      zu 2. IMHO gibt es das, ich meine das paket heißt, xineliboutput-sxfe. Ist aber m.E. nicht HD-fähig.


      dem client ist doch egal ob hd oder sd kommt.
      is hd faehig.


      wird von vdr 1.6.x und auch von vdrdevel 1.7.x verwendet.

    • Quote

      Original von wilderigel
      dem client ist doch egal ob hd oder sd kommt.
      is hd faehig.


      Mir war so, als ob der Client mit dem entsprechenden "vdr-plugin-xineliboutput" zwingend mitgepatched werden muß.


      Kind regards
      hummingbird_de

      HowTo: APT pinning

    • Quote

      Leider gibt es immer wieder einmal Abstürze oder Hänger


      Yepp, es sieht so aus, als gäbe es ein Problem mit dem xineliboutput-Plugin - zumindest bin ich nicht der Einzige, der an der Ecke Abstürze und Hänger hat.
      Die Probleme soll es mit dem xine-Plugin nicht geben - aber die entsprechende Anleitung habe ich noch nicht fertig.
      Wird nachgeliefert, sobald ich eine Lösung gefunden habe.
      Wenn Du aber meine Anleitung genau liest, siehst Du, dass ich mit dem Ergebnis noch nicht zufrieden bin, dass es für mich aber bereits besser als das nach Wickys Anleitung ist.
      Ich denke, man kann sich aus der Anleitung genug für eigene Experimente rausziehen.


      Quote

      was gehoert den vom vdr wohin lt fhs?


      So wie es aktuell beim c't-vdr und dem Ubuntu-Team gehandhabt wird, empfinde ich es als richtig.
      Der VDR hat sein Verzeichnis unter /var/ilb und die Konfigurationsdateien werden nach /etc verlinkt.
      Dass es nach der Installation nach Wickys Anleitung Links unter /etc gibt, die zu keinen Dateien führen ist ein anderes Kapitel und hat nix mit FHS zu tun.


      Quote

      Mir war so, als ob der Client mit dem entsprechenden "vdr-plugin-xineliboutput" zwingend mitgepatched werden muß.


      Wer beide VDR-Versionen (also 1.6x und 1.7x) parallel auf dem Rechner haben will, braucht das nicht zu patchen.
      Ich wollte einen reinen 1.7.x haben und habe es deshalb nicht eingesehen, dass das xinelib-Frontend den kompletten 1.6er Vdr (mit eigenen Verzeichnissen unter /var/lib und /etc, sowie eigenen Startdateien, die den Start von vdr1.7 verhindern) ins System zieht. Deshalb habe ich es gepatched.


      Was die Installation angeht, mag ich eben ent- oder weder, aber nicht beides. Im Mischmasch hat man kaum noch eine Chance Fehler zu finden ...


      Gruß Geronimo

      Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

    • Hallo geronimo,


      ich hätte eine Nachfrage bzgl:


      Quote


      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.



      Wie darf man das verstehen?
      Meinst du eine Dualboot-Installation auf zwei verschiedenen Partitionen?


      ansonsten liest sich deine Anleitung schon sehr gut, bin gespannt darauf wenn sie fertig gestellt ist und sie in "produktion" gehen kann ;)


      gruß jens

      HD-VDR (Wohnzimmer)
      HW: Zotac IONITX-F-E, 160GB SSD 2.5" & 320GB HDD 2,5", 2x1GB, Cine S2
      SW: yaVDR 0.6
      VDR:
      HW: SMT-7020S, 160GB Seagate 2.5"
      SW: zen2mms 1.1


    • Quote

      Meinst du eine Dualboot-Installation auf zwei verschiedenen Partitionen?


      Ja genau.


      Da ich nur einen ION mit VDPAU habe, habe ich 4 Partitionen gemacht und teste 4 verschiedene Systeme/Installationen (ich habe noch nicht rausgefunden, wie ich ein installiertes System in eine Virtualbox überführen kann).
      Da ist es natürlich ätzend, wenn jedes System auf dem Rechner per DHCP über seine MAC jeweils die gleiche IP erhält. Dann gibt es nämlich auf dem Desktop die Fehlermeldung, dass jemand den Rechner sabotiert hat und dass die Schlüssel nimmer übereinstimmen - und jedesmal die .ssh/known_hosts zu löschen nervt auch irgendwann.


      Ich habe das deshalb an der Stelle erwähnt, weil wenn man die Netzwerk-Adresse über die ssh-Konsole ändert und ein /etc/init/networking restart absetzt, anstatt zu booten, dann hängt sich die ssh-Sitzung auf - Logisch ;)


      Quote

      bin gespannt darauf wenn sie fertig gestellt ist und sie in "produktion" gehen kann


      Darauf bin ich selbst gespannt.
      Werde mir jetzt auch mal einen VGA2Scart-Adapter löten ...
      Mal sehen, ob das was bringt. Vielleicht wird ja auch in der Zwischenzeit das Problem beim xineliboutput-Plugin behoben ;)


      Gruß Geronimo

      Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

    • Quote

      Original von geronimo
      Da ist es natürlich ätzend, wenn jedes System auf dem Rechner per DHCP über seine MAC jeweils die gleiche IP erhält. Dann gibt es nämlich auf dem Desktop die Fehlermeldung, dass jemand den Rechner sabotiert hat und dass die Schlüssel nimmer übereinstimmen - und jedesmal die .ssh/known_hosts zu löschen nervt auch irgendwann.


      /etc/ssh/*key* syncronisieren, dann sollte ssh nimma meckern.

    • hi,


      super Anleitung!
      Hab dannach einen Kernel gebacken- was auch funktioniert hat, was nicht klappt ist leider die Header installieren, ich bekomme folgende Fehlermeldung:


      Code
      1. Richte linux-headers-2.6.32.2-htpc ein (2.6.32.2-htpc-10.00.Custom)
      2. ... dpkg: Warnung: veraltete Option »--print-installation-architecture«, bitte verwenden Sie »--print-architecture« stattdessen.


      Hast du eine Idee woran das liegen könnte?

      DVB Server Triax TSS400 SAT>IP Server
      VDR Server Synlogy Diskstation DS214play, debian chroot headless streaming Sever, VDR 2.1.7 mit vtuner/satip und vdr-plugin-satip
      VDR Client AMD X2 250, 4GB DDR3, G210 Passiv, 64GB SSD, Antec Fusion Micro iMON, Samsung LE 40 A659, Teufel E300, Logitech Harmony, yaVDR0.5 streamdev-client, (satip & USB DVBSKY S960 fallback)
      VDR Client Raspberry PI B+, raspian wheezy, VDR 2.1.6 mit RpiHDDevice, streamdev-client
      V/A Clients Windows PC's, Tablet, Smartphones via Streamdev or SatIP (UPNP)

    • Quote

      /etc/ssh/*key* syncronisieren, dann sollte ssh nimma meckern.


      Lässt sich das automatisieren? - denn das wäre ja nach jedem Systemwechsel auf dem vdr fällig.
      Wenn nicht, ist die known_hosts löschen auch nicht mehr Tipparbeit.


      Quote

      Hast du eine Idee woran das liegen könnte?


      Kann es sein, dass Du Ubuntu und kein Debian verwendest?


      Als ich mit dem Rezept anfing, war 2.6.32 aktuell - habe es also locker 20mal durchexerziert, aber die Fehlermeldung ist bei mir nicht aufgetreten.
      Könnte es sein, dass Du iregendwo nen Bindestrich statt einem Unterstrich verwendet hast?
      Ansonsten muss ich passen - bei mir funzt es nach wie vor.


      Gruß Geronimo

      Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

    • brauchst ja nur einmal machen.


      suchst dir ne partition aus von wo du die *key* nimmst und kopierst es auf alle anderen partitionen.


      dann noch einmal die known_hosts anpassen falls erforderlich und ruhe ist.

    • Quote

      Original von geronimo


      Kann es sein, dass Du Ubuntu und kein Debian verwendest?


      treffer.. dachte das verfahren wäre das selbe..

      DVB Server Triax TSS400 SAT>IP Server
      VDR Server Synlogy Diskstation DS214play, debian chroot headless streaming Sever, VDR 2.1.7 mit vtuner/satip und vdr-plugin-satip
      VDR Client AMD X2 250, 4GB DDR3, G210 Passiv, 64GB SSD, Antec Fusion Micro iMON, Samsung LE 40 A659, Teufel E300, Logitech Harmony, yaVDR0.5 streamdev-client, (satip & USB DVBSKY S960 fallback)
      VDR Client Raspberry PI B+, raspian wheezy, VDR 2.1.6 mit RpiHDDevice, streamdev-client
      V/A Clients Windows PC's, Tablet, Smartphones via Streamdev or SatIP (UPNP)