dvbhddevice mit e-Tobi VDR

Sehe das genau gleich!

Aber bis das geschieht, dauert es eben.
Ist ja nicht so als würde es kein Aufwand darstellen und es benötigt natürlich auch noch genügend Know-How dazu. Hut ab vor denen die es haben!

Beim nächsten Debian Stable Release wird es dann aber sicher soweit sein

mfg

Es gäbe ja noch den Weg den Treiber gleich mit ins Kernel Packet zu packen. AFAIK ist so was (Fremdtreiber mit ins Kernelpacket zu bauen) auch vorgesehen (für die Debian Kernelpackete). Dann müsste der HD FF Nutzer halt nur das Kernelpacket wählen welches diesen Treiber enthält.

cu

Also ein extra Kernelpaket für einen einzigen Treiber?
Vorallem muss dann daran gedacht werden, dass der Kernel auch gewartet werden muss, was den Aufwand um vieles erhöht.

Die beste Idee wäre vermutlich den Treiber zu mergen und ihn als dkms-Paket zur Verfügung zu stellen. Wer meldet sich freiwilig?

Zitat von aelo

Also ein extra Kernelpaket für einen einzigen Treiber?
Vorallem muss dann daran gedacht werden, dass der Kernel auch gewartet werden muss, was den Aufwand um vieles erhöht.

Ach, gerade Debian Packetnutzer sind da ja sehr konservativ und verwenden ihren Kernel gerne länger. Und wenn man nen guten Kernel gefunden hat sollte man IMHO auch dabei bleiben, bis jetzt hatte ich bei jedem neuen Kernel auch neue Probleme an denen ich erst fummeln musste.

Wobei es unter Debian auch kein großer Aufwand ist sich den Quellcode für den aktuell genutzten Kernel zu holen (apt-get source), den Treiber dort reinzupacken (hier wurde irgendwo das passende gepostet), seine Kernelconfig dort reinzupacken und ein aktuallisiertes Kernelpacket zu bauen. Ist voll Debian like und man hat den Vorteil das man den Kernel gleich noch entschlacken kann (initial Ramdisk weg, überflüssige Module raus usw.).

Ich habe auch irgendwie den subjektiven Eindruck das das ganze System dann etwas fluffiger läuft.

cu

Zitat von thoand

ich verstehe immer noch nicht, wo das Problem ist gegen den installierten Kernel zu kompilieren, ich mache das jedenfalls bis es offiziell im Kernel ist und auch dann noch, wenn der aktuelle Entwicklungssnapshot besser ist.

Ich sehe da kein Problem. Es gibt halt mehrere Wege.

Wobei ich meinen Kernel wegen spezieller Hardware eh selber kompilieren muss. Von da aus habe ich mich mit diesen Weg angefreundet und sehe auch die weiteren Vorteile wenn man das tut.

cu

Hallo,

ich versuche derzeit einen e-Tobi VDR mit hineingereichter S2-6400 in einer eigenen XEN-DomU zum spielen zu bekommen. Da als Basis der XEN-c't-Server 4 zum Einsatz kommt, muss ich leider mit dem älteren Kernel 2.6.26-2-xen-amd64 vorlieb nehmen. Bisher habe ich mich an dieser Anleitung orientiert und war bis zum dvbhddevice-Plugin erstellen auch erfolgreich.

Da die DomU unter lenny läuft, ist die vdrdevel Version von e-Tobi 1.7.16-1devel1. Um nun das dvbhddevice zu übersetzen bin ich wie folgt vorgegangen:

p2p:/usr/local/src/vdr-1.7.16# dpatch apply-all
applying patch 04_newplugin to ./ ... ok.
applying patch 06_default_svdrp_port_0 to ./ ... ok.
applying patch 11_sortrecordings to ./ ... ok.
applying patch 12_osdbase-maxitems to ./ ... ok.
applying patch 16_channels.conf.terr-fix to ./ ... ok.
applying patch 81_Make_config to ./ ... ok.
applying patch 82_valgrind to ./ ... ok.
applying patch 99_ncursesw-include to ./ ... ok.
applying patch 99_vdr-workaround-broken-sys-capability to ./ ... ok.


p2p:/usr/local/src/vdr-1.7.16# cd PLUGINS/src


p2p:/usr/local/src/vdr-1.7.16/PLUGINS/src# hg clone http://powarman.dyndns.org/hgwebdir.cgi/dvbhddevice/
destination directory: dvbhddevice
requesting all changes
adding changesets
adding manifests
adding file changes
added 50 changesets with 123 changes to 17 files
updating working directory
17 files updated, 0 files merged, 0 files removed, 0 files unresolved


p2p:/usr/local/src/vdr-1.7.16/PLUGINS/src# cd /usr/local/src/vdr-1.7.16/


p2p:/usr/local/src/vdr-1.7.16# make plugins
Plugin dvbhddevice:
make[1]: Entering directory `/usr/local/src/vdr-1.7.16/PLUGINS/src/dvbhddevice'
make[1]: Leaving directory `/usr/local/src/vdr-1.7.16/PLUGINS/src/dvbhddevice'
make[1]: Entering directory `/usr/local/src/vdr-1.7.16/PLUGINS/src/dvbhddevice'
g++ -g -Wall -Woverloaded-virtual -Wno-parentheses -O2 -fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvbhddevice"' -I/usr/include/dvb-s2api-liplianin -I../../../include dvbhddevice.c
g++ -g -Wall -Woverloaded-virtual -Wno-parentheses -O2 -fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvbhddevice"' -I/usr/include/dvb-s2api-liplianin -I../../../include bitbuffer.c
g++ -g -Wall -Woverloaded-virtual -Wno-parentheses -O2 -fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvbhddevice"' -I/usr/include/dvb-s2api-liplianin -I../../../include dvbhdffdevice.c
g++ -g -Wall -Woverloaded-virtual -Wno-parentheses -O2 -fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvbhddevice"' -I/usr/include/dvb-s2api-liplianin -I../../../include hdffcmd.c
g++ -g -Wall -Woverloaded-virtual -Wno-parentheses -O2 -fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvbhddevice"' -I/usr/include/dvb-s2api-liplianin -I../../../include hdffosd.c
hdffosd.c: In member function ‘virtual void cHdffOsdRaw::Flush()’:
hdffosd.c:641: error: ‘IsTrueColor’ was not declared in this scope
hdffosd.c:643: error: ‘LOCK_PIXMAPS’ was not declared in this scope
hdffosd.c:644: error: ‘cPixmapMemory’ was not declared in this scope
hdffosd.c:644: error: ‘pm’ was not declared in this scope
hdffosd.c:644: error: ‘RenderPixmaps’ was not declared in this scope
hdffosd.c:662: error: type ‘<type error>’ argument given to ‘delete’, expected pointer
make[1]: *** [hdffosd.o] Fehler 1
make[1]: Leaving directory `/usr/local/src/vdr-1.7.16/PLUGINS/src/dvbhddevice'
*** failed plugins: dvbhddevice


make: *** [plugins] Fehler 1
p2p:/usr/local/src/vdr-1.7.16#

Leider funktioniert dies - wie oben zu sehen - nicht. Variante zwei von aelo (Post 3) kann ich aufgrund der niedrigeren vdr-Version nicht benutzen

Hat mir irgendjemand einen Tipp, wie ich noch vorgehen könnte?

Danke im Voraus,
Gruß livefields

Laut Errorlogs benötigt das HDFF-Plugin das TrueColor-Feature und damit läuft es erst ab VDR >= 1.7.17.

Sollte es für Lenny wirklich keine neueren Pakete geben, fügst du dir die deb-src-Codezeile des Squeeze-Repository zu deiner sources.list und baust dir die Pakete neu. Danach kannst du meine Paketvorlagen aus folgendem Thread nehmen und das Plugin bauen. (Davor bitte auch noch den Treiber für die HDFF kompilieren und die Firmware an den richtigen Ort kopieren.)

Paketsourcen für dvbhddevice-Plugin:
dvbhddevice mit e-Tobi VDR
Eventuell noch den aktuellen Sourcecode darüber koppieren: http://powarman.dyndns.org/hgwebdir.cgi/dvbhddevice/

mfg
aelo

Erst mal Danke für Deine schnelle Antwort, aelo.

Zitat von aelo

Laut Errorlogs benötigt das HDFF-Plugin das TrueColor-Feature und damit läuft es erst ab VDR >= 1.7.17.

Sollte es für Lenny wirklich keine neueren Pakete geben, fügst du dir die deb-src-Codezeile des Squeeze-Repository zu deiner sources.list und baust dir die Pakete neu.

Heißt Pakete neubauen den vdr aus den "squeeze-Quellen" übersetzen oder meinst Du hier nur das dvbhddevice-Plugin? Das Plugin selbst dürfte ja dann mit einem vdr 1.7.16 gar nicht tun, oder?

Zitat von aelo

Danach kannst du meine Paketvorlagen aus folgendem Thread nehmen und das Plugin bauen. (Davor bitte auch noch den Treiber für die HDFF kompilieren und die Firmware an den richtigen Ort kopieren.)

Sehe ich das richtig, das dies dann nur noch nötig ist, wenn ich mir ein .deb-Paket erstellen will?

Am PC tippt es sich doch ein wenig besser als am Smartphone :-). Deshalb nun etwas genauer:

Voraussetzungen:
* Neuere VDR-Version

Deine Möglichkeiten:
* Direktes bauen des Sourcecodes mit configure und make. Dies ist allerdings die unsaubere Variante.
* Selber debianisieren. Sehr viel Aufwand!
* Die Sourcen von Squeeze nehmen damit du eine Vorlage hast und diese dann ganz simple neu kompilieren kannst unter Lenny.

Ein weiterer Nachteil beim VDR ist dass es hier schon sehr viele Skripte und Configfiles gibt. Diese werden bei der Debian-Vorlage mitinstalliert und du brauchst dich nicht darum kümmern. Bei den anderen Varianten musst du dich selber um doch einige config-Files, init.d-Scripte und der gleichen kümmen. Dies würde natürlcih einen hohen Aufwand bedeuten.

Meine persönliche Empfehlung:
Füge folgende Zeile in der /etc/apt/sources.list hinzu:

deb-src http://e-tobi.net/vdr-experimental squeeze vdr-multipatch addons base backports

Führe dann folgende Befehle aus:

su
apt-get update
exit
cd ~/
mkdir vdrsrc
cd vdrsrc
apt-get source vdr vdr-plugin-live vdr-plugin-epgsearch vdr-plugin-streamdev # und weitere Plugins nach Wahl

Dann hast du die Sourcefiles des VDR's und einiger Plugins schon mal in diesem Ordner abgelegt.

Dann wechselst du in die einzelnen Ordner (beginnend mit dem VDR!!!!) und führst folgendes aus:

apt-get build-dep vdr
dpkg-buildpackage -tc -us -uc
cd ..
dpkg -i vdr_*deb
dpkg -i vdr-dev_*deb

Bei den oben genannten Plugins gibt es vielleicht noch ein deb-File mehr oder weniger (-dev haben die z.B. nicht) aber ansonsten funktioniert das gleich bzw. ähnlich.

Dann installierst du dir den Treiber für die S2-6400 wie es in anderen Threads bereits beschrieben ist. (Habe die Karte nicht und kann dir deshalb auch keine genaue Beschreibung geben.)

Danach kompilierst du nun das dvbhddevice-Plugin!
1. Lade dir die Vorlage von hier herunter: dvbhddevice mit e-Tobi VDR
2. Entpacke das File.

Und nun kompiliere das Plugin

dpkg-source -x vdr-plugin-dvbhddevice*dsc
cd vdr-plugin-dvbhddevice...
dpkg-buildpackage -tc -us -uc
dpkg -i ../vdr-plugin-dvbhddevice*deb
su -c '/etc/init.d/vdr restart'

Die channels.conf musst du dir noch anlegen und danach kannst du die S2-6400 verwenden. Zumindest theoretisch

mfg
aelo

Wow, tolle Anleitung. Schon mal herzlichen Dank dafür aelo!!!

Ich werde versuchen das umzusetzen und berichten, ob und wie es geklappt hat.

So, also ich hab die /etc/apt/sources.list um die genannte Zeile erweitert und habe mir die Pakete gezogen. Wenn ich nun allerdings apt-get build-dep vdr ausführen will kommt Folgendes:

p2p:~/vdrsrc/vdr-1.7.18# apt-get build-dep vdr
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut       
Lese Status-Informationen ein... Fertig
E: Build-Depends-Abhängigkeit für vdr kann nicht erfüllt werden, da keine verfügbare Version von Paket debhelper die Versionsanforderungen erfüllen kann.
p2p:~/vdrsrc/vdr-1.7.18#

Liegt wohl also an einem zu alten debhelper. Den konnte ich noch über einen aus dem lenny-backports Repository ersetzen, aber jetzt knallts schon wieder:

p2p:~/vdrsrc/vdr-1.7.18# apt-get build-dep vdr
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut       
Lese Status-Informationen ein... Fertig
E: Build-Depends-Abhängigkeit für vdr kann nicht erfüllt werden, da keine verfügbare Version von Paket linux-libc-dev die Versionsanforderungen erfüllen kann.
p2p:~/vdrsrc/vdr-1.7.18#

Ich kenn mich nicht genau aus, aber die Linux-Headerdateien zu ersetzen hört sich nicht trivial an. Die müssen doch zum Kernel passen, oder? Oh je, den upzudaten mit dem ganzen XEN-Gedöns hatte ich eigentlich nicht vor...

Da gibt es nun zwei Möglichkeiten:
a) Die Versionen wurden eben weil es für Squeeze kompiliert wurde so hoch angegeben.
b) VDR benötigt wirklich diese Versionen.

Du könntest nun versuchen die Sourcen von folgendem Link manuell herunterzuladen, zu entpacken (dpkg-source -x *.dsc) und dann in der debian/control die Versions-Info zu entfernen und zu versuchen ob das ganze kompiliert
http://e-tobi.net/vdr-experime…ze/source/vdr-multipatch/

Ansonsten ersparst du dir vermutlich einiges an Ärger wenn du einfach auf Squeeze updatest, auch wenn es etwas Arbeit ist...

mfg

Hallo ,

danke für das deb-Paket, wenn ich versche das zu installieren kommt folgende Fehlermeldung

vdr-abi-1.7.18-multipatch ist nicht installiert, woher bekomme ich den denn ?

System ist c't vdr,

danke und mfg

Das Paket ist inzwischen veraltet, lade dir die neueren Pluginsourcen herunter.