vdr und Plugins compilieren/debianisieren

scovery · 5. Februar 2006

Hallo,

versuche gerade durchzublicken, wie vdr bzw. bei der Distribution nicht vorhandene Plugins (etwa lnb-sharing) selbst compiliert werden können.

Habe erst mal die vdr-Sourcen und nötigen Tools per apt-get besorgt. Ein debian/rules binary (entsprechend der Anleitung auf http://www.heise.de/ct/ftp/projekte/vdr/develop.shtml) im vdr source (1.3.37) Vereichnis erzeugt auch auf Anieb (offenbar fehlerfrei) folgende deb's:

vdr-dev_1.3.37-1ctvdr1_all.deb
vdr_1.3.37-1ctvdr1_i386.deb
vdr-plugin-examples_1.3.37-1ctvdr1_i386.deb
vdr-dbg_1.3.37-1ctvdr1_i386.deb
vdr-plugin-sky_1.3.37-1ctvdr1_i386.deb

Jetzt kommen aber die Fragen:

(1) Könnte die eben compilierte vdr_1.3.37-1ctvdr1_i386.deb (nach apt-get remove vdr) einfach statt des aktuellen vdr installeirt werden (Anmerkung: ist eh ein Test-System)?
(2) Beim compilieren müssen doch ggf. auch bestimmte Parameter/Optionen gesetzt werden - wo können diese "untergebracht" werden?
(3) Müssen alle Plugin-Sourcen der Plugins, die mit vdr verwendet werden sollen, komplett mit ins vdr Source Plugin Verzeichnis (wie bei dem in der vdr-Source mitgelieferten plugin-examples)?
(4) Müssen überhaupt alle Plugins immer auch neu compiliert werden, wenn vdr neu compiliert wird? Nach dem Abschnitt "Ein Plug-in debianisieren" auf der genannten c't-Seite ja eher nicht?

Da war doch auch mal irgendwo ein Howto? Auf e-tobi.net finde ich aber zumindest nichts mehr...

Thx.

Markus23 · 5. Februar 2006

tja ich bin da gerade an nem ähnlichen Problem..

ich hab mir laut e-tobi Seite entsprechendes vdr-sourcen gezogen und installiert und hab dann lt. der Anleitung auch den vdr übersetzen können..
Auch das Beispiel mit den mp3 plugin konnte ich nachvollziehen und compilieren..
Aber das waren ja quasi auch alles debianisierte Sourcen vom e-tobi repository.

dann hab ich versucht das recstatus-plugin ( ganz einfaches plugin ) zu debianisieren und zu compilieren , aber ich bekomme immer fehlermeldungen des compilers der irgendwelche includes nicht finden kann, und das ob ich mir zum Vergleich mal das sleeptimer-plugin (sourcen) von e-tobi geholt habe und mal alle einstellungen in debian/* und auch selbst im eigentlichen Makefile kontrolliert habe und keinerlei unterschiede gefunden habe ...

in beiden Plugins wird g++ mit den Optionen [...]-I/usr/include/vdrdevel/include -I/usr/include[...] aufgerufen , aber komischerweise klappt das compileren beim e-tobi sleeptimer plugin 1a und bei meinem rectimer plugin kommen fehlermeldungen , dass er die includes z.b. include=/vdr/menu.h oder include=/vdr/plugin.h nicht finden kann..

Sleeptimer hat aber direkt in der sleeptimer.c datei genau die gleichen includes ?

Ich blicks ned :-/

bye, Markus

scovery · 5. Februar 2006

Ich bin zumindest doch noch auf e-tobi.net fündig geworden. Muss man aber auch erst drauf kommen dass Dokumentationen irgendwo unter blog vergraben und nicht unter VDR zu finden sind...

Markus23 · 5. Februar 2006

Moinsen !

So mit der richtigen Anleitung (eben die aus dem Blog von e-tobi) , hab ich es auch hinbekommen das ganz einfache Recstatus-Plugin zu compilieren und zu debianisieren ..

funzt einfach - wenn man weiss wie es geht

Nun fehlt mir nur noch die Anleitung wie ich den DVB-Treiber aus dem CVS passend zu installierten Kernel compilieren und debianisieren kann.

Konnte mit bisher keiner weiterhelfen ...

scovery · 5. Februar 2006

Zitat

Original von Markus23
funzt einfach - wenn man weiss wie es geht

Naaaajaaa - also ich wollte ja lnb-sharing ausprobieren. Dazu ist lediglich vdr zu patchen und neu zu kompilieren. Theoretisch - praktisch aber mit der Folge dass sämtliche Plugins nicht mehr passen obwohl man meinen könnte sind ja die identischen benutzten c't Sourcen - aber selbst unverändert passt nichts! Hieße alle Plugins zusammen suchen und neu machen
Und vdr für einen Wechsel zu deinstallieren funktioniert auch nicht wirklich problemlos, weil alle möglichen Sachen mit deinstalliert werden und nachher bei erneuter Installation fehlen Also hab ich letztlich nur /usr/bin/vdr ausgetauscht
Zumindest konnte ich (nachdem die Plugins rausgworfen waren) jetzt zumindest ausprobieren, ob das Sharing klappen würde. Scheint tadellos zu laufen. Schade, dass das nicht auch gleich bei der Distri. mit eingearbeitet ist, würde ja im Normalbetrieb gar nicht stören.

TomG · 5. Februar 2006

Zitat

Original von scovery
Schade, dass das nicht auch gleich bei der Distri. mit eingearbeitet ist, würde ja im Normalbetrieb gar nicht stören.

In VDRdevel hatte ich den Patch lange Zeit drin, hab ihn dann rausgenommen, weil er im Normalbetrieb doch gestört hat. Ob das mit der aktuellen Version des Sharelnb-Patches noch so ist, weiß ich nicht. Zur Zeit komme ich nicht dazu, es auszuprobieren.

Tom

scovery · 6. Februar 2006

Zitat

Original von TomG
[In VDRdevel hatte ich den Patch lange Zeit drin, hab ihn dann rausgenommen, weil er im Normalbetrieb doch gestört hat.

Welche Störungen gab es? Beim bisherigen Normalbetrieb (DVB-Empfänger auf unterschiedlichen LNBs) ist mir noch nichts aufgefallen. Und hier im Forum habe ich auch spontan keine auffälligen Fehlermeldungen diesbezüglich gefunden (außer dem was ich auch selbst festgestellt habe, nämlich dass sich nicht gleichzeitig der Lifebuffer-Patch anwenden lässt).

Aber apropos Patch: müssten die Plugins nicht nach wie vor passen, wenn ich die zur Distri. gehörenden c't 4.5 VDR Sourcen genommen habe? Habe ich vielleicht nur nicht die gleichen Patches in 00list aktiviert (zumindest jetzt LNB-Sharing)? Wo ist eigentlich nachzulesen welche Patches in der Distri. verwendet wurden? In der multipatch.00list?
[edit] Oder kann es sein dass die Plugins deshalb nicht mehr passen weil ich durch ein apt-get upgrade möglicherweise neuere Debian Libraries bekommen habe? [/edit]

[nochmal edit]
Hat sich geklärt - (nur) mit den Patches aus multipatch.00list laufen die ursprünglichen Plugins der Distri. wieder.

Markus23 · 6. Februar 2006

Zitat

Original von TomG
In VDRdevel hatte ich den Patch lange Zeit drin, hab ihn dann rausgenommen, weil er im Normalbetrieb doch gestört hat

Das kann ich insofern bestätigen, als dass ich unter Linvdr+Bigpatch-All-In-One-Paket mit diesem LNB-Sharing-Patch und 2 DVB-Karten die auch noch jeweils 2 Sattelliten per Diseqc angesprochen haben, doch richtig komische Probleme hatte , dass manchmal kein Umschalten und Aufnehmen mehr möglich war.

Nachdem ich jetzt auf ct'-vdr 4.5 bin und diesen Patch nicht mehr drin habe, keinerlei Probs mehr.

Also bitte den Patch lieber nur als Option drin lassen ..

TomG · 6. Februar 2006

Zitat

Original von scovery
Welche Störungen gab es? Beim bisherigen Normalbetrieb (DVB-Empfänger auf unterschiedlichen LNBs) ist mir noch nichts aufgefallen. Und hier im Forum habe ich auch spontan keine auffälligen Fehlermeldungen diesbezüglich gefunden (außer dem was ich auch selbst festgestellt habe, nämlich dass sich nicht gleichzeitig der Lifebuffer-Patch anwenden lässt).

Konflikte mit anderen Patches meine ich nicht, die sind meist irgendwie zu lösen.

Es gab vor allem Probleme mit dem EPG-Scan. Mit einer Karte wurde der dann gar nicht mehr ausgeführt.

Zitat

Aber apropos Patch: müssten die Plugins nicht nach wie vor passen, wenn ich die zur Distri. gehörenden c't 4.5 VDR Sourcen genommen habe? Habe ich vielleicht nur nicht die gleichen Patches in 00list aktiviert (zumindest jetzt LNB-Sharing)? Wo ist eigentlich nachzulesen welche Patches in der Distri. verwendet wurden? In der multipatch.00list?

Ich sehe schon, du willst es ganz genau wissen.

Dazu muss ich wohl etwas weiter ausholen. Die Verbindung zwischen VDR und den Plugins ist ziemlich eng. Der VDR ruft Funktionen bzw. Methoden der Plugins auf und umgekehrt. Wenn die Aufrufparameter nicht stimmen, gibt es Probleme. Wenn man alles zusammen übersetzt, werden sie meist sofort sichtbar.

Die Debianpakete werden aber einzeln übersetzt. Deshalb kommt es beim Packen der Plugin-Pakete darauf an, das passende vdr(devel)-dev-Paket installiert zu haben, denn in den Headerdateien sind die Schnittstellen definiert, d.h. die Funktionen/Methoden mit ihren Aufrufparametern.

Die meisten Patches ändern die Schnittstellen. Je nachdem, ob ein Plugin diese Schnittstelle benutzt, kann es funktionieren oder nicht. Wenn es nicht funktioniert, dann kann das sehr vielfältige Auswirkungen haben: von seltsamem Programmverhalten bis zum Absturz des ganzen VDR.

Deshalb versuchen wir, das Einbinden nicht kompatibler Plugins zu verhindern, indem die Patchlevel verglichen werden, die beim Übersetzen der Pakete wirksam waren.

Dieser Patchlevel-Test lässt sich in /etc/default/vdr(devel) abschalten (auf eigene Gefahr). Das wäre z.B. eine Möglichkeit einen Patch einzubauen, ohne alle Plugins neu zu übersetzen. Unter der Annahme, dass der Patch mit den verwendeten Plugins keine Probleme bereitet.

In diesem Fall wäre auf jeden Fall wichtig, den zweiten Plugin-Test eingeschaltet zu lassen (PLUGIN_CHECK_STARTABLE). Dieser Test ruft für jedes Plugin "vdr -V -Ppluginname" auf, wodurch die meisten Inkompatibilitäten (aber sicher nicht alle) auffallen und die entsprechenden Plugins nicht eingebunden würden.

Ich hoffe, ich habe dich jetzt nicht vollends verwirrt. Die sicherste Methode, mit eigenen Patch-Kombinationen klar zu kommen, ist immer alle verwendeten Plugins mit dem neuen vdr(devel)-dev-Paket neu zu übersetzen. apt-get hat dafür eine sehr elegante und schnelle Möglichkeit: "apt-get source --build vdr(devel)-plugin-... vdr(devel)-plugin-... ..."

Zitat

[edit] Oder kann es sein dass die Plugins deshalb nicht mehr passen weil ich durch ein apt-get upgrade möglicherweise neuere Debian Libraries bekommen habe? [/edit]

Das ist eher unwahrscheinlich und wäre ein Fehler in den Libraries.

Tom

scovery · 6. Februar 2006

Zitat

Original von Markus23
mit diesem LNB-Sharing-Patch und 2 DVB-Karten die auch noch jeweils 2 Sattelliten per Diseqc angesprochen haben, doch richtig komische Probleme hatte

Das habe ich auch - und zumindest bisher keine Probleme bemerkt. Denkbar wäre vielleicht ein Versatz zwischen dem DiSEqC-Signal und dem Umschalten wegen der LNB-Zuordnungsroutine. Schon mal mit doppelten "Absetzen" des DiSEqC-Signals in der diseqc.conf probiert gehabt?

Ich habe eher den Eindruck, dass Livebuffer einiges versaubeutelt. Leider funktionieren ohne diesen Patch viele Plugins selbst nach Neukompilation nicht mehr (finde ich ziemlich merkwürdig).

Zitat

Original von TomG
Konflikte mit anderen Patches meine ich nicht, die sind meist irgendwie zu lösen.

So weit das zu lösen (siehe Konflikt LNB-Sharing und Livebuffer) bin ich noch nicht

Zitat

Original von TomG
Es gab vor allem Probleme mit dem EPG-Scan. Mit einer Karte wurde der dann gar nicht mehr ausgeführt

Das wäre ja irgendwie nachvollziehbar dass es problematischer wird, alle Sender zu scannen.

Zitat

Original von TomG
Ich sehe schon, du willst es ganz genau wissen.

Will mal eher so sagen: Computer bzw. Compiler sind da ziemlich pingelig und wenn's nicht passt stellen die sich einfach quer

Zitat

Original von TomG
Wenn die Aufrufparameter nicht stimmen, gibt es Probleme. Wenn man alles zusammen übersetzt, werden sie meist sofort sichtbar.

Die Debianpakete werden aber einzeln übersetzt.

Das mit dem einzeln habe ich jetzt auch soweit bemerkt. Nur: Bei der vdr Source sind ja doch Plugins(-Beispiele) dabei, die dann doch gleich mit dem vdr compiliert werden.

Zitat

Original von TomG
Deshalb versuchen wir, das Einbinden nicht kompatibler Plugins zu verhindern, indem die Patchlevel verglichen werden

Das ist mir auch klar geworden - und das man das abstellen kann. Nur wie kann es dann kommen, dass trotzdem z.B. streamdev-server eine Inkompatibilität hervorruft, wenn der Livebuffer-Patch weggelassen wird?! Muss ich nochmal verifizieren (d.h. sowohl vdr und streamdev ohne Livebuffer-Patch compilieren und dann zusammen probieren) - aber bin mir eigentlich sicher dass es so nicht mehr klappt.

TomG · 6. Februar 2006

Zitat

Original von scovery

Das wäre ja irgendwie nachvollziehbar dass es problematischer wird, alle Sender zu scannen.

Der EPG-Scan ging gar nicht mehr. Für Einkartensysteme gibt es eine Einstellung "Zeit bis zum EPG-Scan". Wenn man dort 2 Stunden einträgt, dann wird 2 Stunden nach der letzten Benutzeraktion der EPG-Scan über alle Sender angeworfen. Der Bildschirm bleibt während des Scans dunkel.

Zitat

Das mit dem einzeln habe ich jetzt auch soweit bemerkt. Nur: Bei der vdr Source sind ja doch Plugins(-Beispiele) dabei, die dann doch gleich mit dem vdr compiliert werden.

Das ist die Ausnahme zu der Regel.

Zitat

[quote]Original von TomG
Nur wie kann es dann kommen, dass trotzdem z.B. streamdev-server eine Inkompatibilität hervorruft, wenn der Livebuffer-Patch weggelassen wird?! Muss ich nochmal verifizieren (d.h. sowohl vdr und streamdev ohne Livebuffer-Patch compilieren und dann zusammen probieren) - aber bin mir eigentlich sicher dass es so nicht mehr klappt.

Hast du auch das richtige vdr-dev-Paket installiert, d.h. das von dir neu erzeugte?

Tom

scovery · 6. Februar 2006

Also ich habe jetzt soeben (sauber) das Weglassen von Lifebuffer verifiziert.

(erneut) apt-get source vdr
00list wie in multipatch.00list, nur Livebuffer auskommentiert
debian/rules binary
dpkg -i vdr_1.3.37-1ctvdr1_i386.deb

(erneut) apt-get source vdr-plugin-streamdev
debian/rules binary
dpkg -i vdr-plugin-streamdev-server_0.3.1+cvs20050522-13_i386.deb

vdr -V -P streamdev-server
meckert nicht.
Starte ich vdr jedoch erneut wird das streamdev-server Plugin wegen "really binary incompatibility" nicht geladen. Patchlevel-Check habe ich mal deaktiviert, da ich die Angaben auf die Schnelle nicht angepasst habe.

scovery · 6. Februar 2006

Zitat

Original von TomG

Das ist die Ausnahme zu der Regel.

Ah ja - also einfach ignorieren?!

Zitat

Original von TomG
Hast du auch das richtige vdr-dev-Paket installiert, d.h. das von dir neu erzeugte?

Ähm - jetzt kommen wir der Sache vielleicht näher. Wird das dann für das Compilieren der Plugins benutzt? Macht viellelicht irgendwie Sinn

scovery · 6. Februar 2006

Sag doch: Computer und Compiler sind pingelig - was so ein kleines

dpkg -i vdr-dev_1.3.37-1ctvdr1_all.deb

für einen Unterschied macht - jetzt klappt's

Für mich war eben verwirrend, was beim vdr-Compilieren mit erzeugt wird (auch die Plugins). Dass das vdr-dev benötigt wird war nicht ersichtlich. Und ich hab mich eben genau das gefragt, nämlich: wie sollen die Plugins was von einer vdr-Änderung mitbekommen, wenn die woanders compiliert werden. Jetzt sind allle Klarheiten beseitigt

Danke Tom.

scovery · 6. Februar 2006

Ah ist das ein Sch... mit den Pugins compilieren.

Versuche es jetzt schon 2 Stunden mit ospip und komme einfach nicht weiter. Offenbar fehlen ffmpeg-Sourcen, die es offensichtlich nicht per apt-get gibt. Mit den CVS-Sourcen bin ich auch nicht wirklich weiter gekommen - es wird auch versucht ffmpeg-config auszuführen, das es überhaupt nicht gibt. Soll wohl in ffmpeg-devel sein - finde ich aber auch nicht

[edit] apt-get install libavcodec-dev hat's gebracht - irgendwie ist flöhehüten einfacher... [/edit]

scovery · 6. Februar 2006

Schön wär's ja gewesen, wenn das erzeugte Plugin wenigstens funktionieren würde. Aber keine OSD-Anzeige vom Plugin, keine Fehlermeldung.

[edit]
Komisch, nachdem die Werte in vdr/OSD für's Plugin geändert wurden bzw. einfach neu gespeichert ging es plötzlich.

Markus23 · 6. Februar 2006

hmm

So ganz kann ich deine Probleme nicht nachvollziehen...

Ok ich bin direkt nach der ct'-vdr 4.5 Installation zum vdrdevel Zweig gewechselt und hab mir den vdrdevel-1.3.41-2 kommt mit allem (Plugins, nvram-wakeup usw.) installiert.

Musste halt mal schauen im Thread vdrdevel-1.3.41 vom TomG.
Dort ist auch angegeben wie man seine sources.list anpassen muss, damit das klappt.

dann einfach mal apt-cache search vdrdevel eingeben, dann siehste alle möglichen vdrdevel Pakete !

Hab dann die instaliert , die ich wollte und gut...

Als nächstes bin ich sogar soweit gegangen und hab mir noch den experimental zweig direkt von der ct' in die sources.list eingebunden und hab mir den kernel-2.6.15-ct1 mit Headers und Quellen installiert.

Ging auch alles 1a.

Nächste Station war anlegen von /usr/src/vdrdevel und der Installation der vdrdevel-1.3.41-2 sourcen in das verzeichnis (apt-get sources vdrdevel-1.3.41-2 in dem verzeichnis!)

dann noch weitere verzeichnisse für meine gewünschten Plugins in /usr/src angelegt (z.b. vdrdevel-plugin-mp3, wieder rein ins verzeichnis , apt-get source vdrdevel-plugin-mp3, apt-get build-dep vdrdevel-plugin-mp3 ) andere plugins analog dazu.

Jetzt in vdrdevel meine geünschten patches aktiviert in der 00list und dann mit dpkg-buildpackage den vdrdevel compiliert und debianisiert ...

Jetzt ERST den neu erstellten vdrdevel-1.3.41.deb UND vdrdevel-1.3.41-dev.deb installiert !

erst jetzt in die jeweiligen plugin-verzeichnisse gewechselt und per dpkg-buildpackage -tc die plugins übersetzt und die erstellten .deb dateien dann wieder installiert.

Ging alles ohne Probs und 1a bei mir , selbst text2skin, osdteletext, streamdev-server , mp3 usw neu compiliert und installiert ..

Ich würde es vielleicht mal mit dem vdrdevel zweig probieren !

[edit]

Gut, wenns jetzt funzt bei Dir ...
Allgemein kann ich den vdrdevel-Zweig nur empfehlen , bisher null probleme mit den (selbsterstellten) Paketen, auch wenns der "Experimental" Zweig ist ...

scovery · 6. Februar 2006

Die Probleme reißen nicht ab:

Code

apt-get build-dep vdr-plugin-image
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut... Fertig
E: Build-Depends Abhängigkeit für vdr-plugin-image kann nicht befriedigt werden, da keine verfügbare Version von Paket libavcodec-dev die Versionsanforderungen erfüllen kann.

In sources.list habe ich:

Code

deb ftp://ftp.de.debian.org/pub/debian sarge main non-free
deb ftp://ftp.de.debian.org/pub/debian-non-US sarge/non-US main
deb-src ftp://ftp.de.debian.org/pub/debian/ sarge main contrib non-free

TomG · 6. Februar 2006

Zitat

Original von scovery
[edit] apt-get install libavcodec-dev hat's gebracht - irgendwie ist flöhehüten einfacher... [/edit]

So einfach kann die Welt sein ...

Wenn du mit dpkg-buildpackage übersetzen würdest, dann würde es dir sagen, welche Pakete du installieren musst. Oder noch einfacher: du führst vorher "apt-get build-dep paketname" aus, das installiert dir die zum Übersetzen benötigten Pakete gleich.

BTW: Ein bisschen Studium der Debian-Doku kann auch nicht schaden ...

Tom

Markus23 · 6. Februar 2006

Huch, ich sollte mich bei Antwort-Schreiben kürzer fassen ..

Das tippt und tippt man und wenn man fertig ist , sind schon 2-3 neue Antworten drunter ;-))

Aber das mit den apt-get build-dep <pluginname> ist auf jeden fall nen guter Tipp

PS:

Gibts eigentlich schon News zu vdrdevel-1.3.42 , Tom ?

vdr und Plugins compilieren/debianisieren

Jetzt mitmachen!

Teilen