VDR Plugin Survey 2008

I've started a small survey about VDR and the VDR plug-ins and kindly ask you to participate.


The main reason for this survey is, that there are currently more than 300 plug-ins available for VDR (according to the English and German VDR Wiki).

That's a lot!

As a member of the Debian VDR packaging project (we currently just have about 120 plug-ins packaged), I would like to know, which are the plug-ins that are really used and which are the ones that aren't used at all.

As a result of this survey, we would like to drop Debian packaging support for some of the rarely and not used plug-ins that are not maintained by their authors anymore and identify interesting plug-ins that might be good candidates for an official release in Lenny +1 .

This survey is not just about the Debian VDR packages. It's main focus is on VDR and VDR plug-ins in general and I hope, it will be useful for other distribution maintainers and developers as well.

I will make the results and all the collected data available to the public under the terms of the Creative Commons Licence (CC-BY-SA), after the survey has been finished.

The survey is completely anonymous! You have to register with an email address and a password, but they will only be stored as an SHA hash in the database and will be randomized once more, before the data is made available to the public. The survey will not send any emails or do other nasty stuff!

If you have any problems with the survey or your are missing a plug-in, just write me a small note to: vdr-plugin-survey-2008@e-tobi.net

Thanks for your participation!

Published on 31/08/2008 at 14:08 by , tags , , ,

New Vodcatcher release

I've just put the a new release of the VDR Vodcatcher plug-in online, which was hanging here around for months.

It now supports playback via Xineliboutput. If you have trouble with Xineliboutput playback, you probably need to increase the PLAYFILE_TIMEOUT in Xineliboutputs frontend_svr.c:

diff -urNad vdr-plugin-xineliboutput-1.0.1~/frontend_svr.c vdr-plugin-xineliboutput-1.0.1/frontend_svr.c
--- vdr-plugin-xineliboutput-1.0.1~/frontend_svr.c  2008-04-23 22:12:58.000000000 +0200
+++ vdr-plugin-xineliboutput-1.0.1/frontend_svr.c   2008-08-10 00:16:25.000000000 +0200
@@ -52,7 +52,7 @@
 #define LOG_OSD_BANDWIDTH (128*1024)  /* log messages if OSD bandwidth > 1 Mbit/s */

 #define PLAYFILE_CTRL_TIMEOUT   300   /* ms */
-#define PLAYFILE_TIMEOUT       5000   /* ms */
+#define PLAYFILE_TIMEOUT      10000   /* ms */

 typedef struct {
   int    Size;

See also: Timeout when starting stream playback

I've already increased the timeout for the Debian package release of vdr-plugin-xineliboutput.

Published on 10/08/2008 at 00:03 by , tags , , ,

VDR plug-in dependencies

In the past, when upgrading Debian VDR and VDR plug-in packages, it could happen, that one or more plug-ins were not updated (maybe because they haven't been uploaded yet or haven't migrated to testing). This could be problematic, because the new VDR might have a changed ABI (Application Binary Interface), causing any old plug-ins to be unloadable due to their ABI incompatibility. Such an ABI incompatibility could also happen, when the VDR package was built with any optional patches, but the plug-in wasn't compiled against the patched VDR headers.

To avoid crashes with such incompatible plug-ins, the wrapper script that starts VDR checked at runtime, if a plug-in matches the "patchlevel" (a string identifier in a custom control field of the Debian package, listing the names of the applied optional patches) and if the plug-in was loadable at all. This check was pretty slow, because it relied on getting the pachtlevel information via dpkg, so we recently introduced some kind of caching, which made the VDR start up procedure even more complicated.

When this topic came up again recently with bug report #489914, I had the idea to replace the weak runtime compatibility test with install time dependency checks using Debians virtual package / "Provides" feature. It's a pretty simple solution and I'm wondering, why I haven't thought about this before.

This is how it works: The VDR-Package has a "Provides: vdr-abi-1.6.0-debian" entry in it's control file and the VDR plug-ins just have a dependency on "vdr-abi-1.6.0-debian". This way you can't install a plug-in without having a compatible VDR installed and vice versa. Any changes in VDR's ABI must be reflected in the virtual package name like "vdr-abi-1.6.0-debian-1" when having added a patch to the Debian package or "vdr-abi-1.6.1-debian" when a new upstream version introduces a new ABI.

Under the hood, there's happening a little bit more. With the VDR header package vdr-dev, /usr/share/vdr-dev/abi-version will be installed, which contains the ABI version name used in the Provides-field. It also installs /usr/share/vdr-dev/dependencies.sh which plug-ins may use to create a ${vdr:Depends) substitution variable, that will hold the correct ABI version name. So everything a plug-in has to do, is to have a "Depends: ${vdr:Depends)" in its control file and to to call dependencies.sh during the build process.

The ABI version name, that the VDR package will use, is specified in debian/abi-version and from there finds it's way to the "Provides"-field in the control file via the ${vdr:Provides} substition variable. It's the package maintainers responsibility to change the ABI version name with every ABI changes that might be introduced in a new package release. The C++ ABI compatibility is well documented by the KDE team in "Policies/Binary Compatibility Issues With C++"

As a small safety network, the VDR package will check at build-time, if any of the applied patches (debian/patches) has been modified, by keeping a list of MD5 sums of all patches in debian/.vdr-patches. If a patch changes, the build will break until the md5 sums are manually updated with debian/rules accept-patches. Before doing this, the package maintainer should check, if any of the changed patches may affect the ABI-version and in this case has to modify the ABI version name in debian/abi-version.

This mechanism also supports building VDR in different "patch flavours". By setting the environment variable "PATCHVARIANT", a different set of patches from debian/patches can be selected. e.g.;

PATCHVARIANT=multipatch dpkg-buildpackage -tc -uc -us -rfakeroot

This will use the patches listed in debian/patches/00list.multipatch and it will use debian/abi-version.multipatch and debian/.vdr-patches.multipatch. The ABI version of such a patch variant should differ from the "vanilla" ABI version and all other patch variants, e.g.; "vdr-abi-1.6.0-multipatch-2008-07-26".

The patch variants included in the packages available at e-tobi.net are "multipatch" and "extensions". The official Debian VDR package will only contain the "multipatch" variant (but only a vanilla VDR is available as binary packages in Debian!).

To build your own patch variant, you have to:

  1. copy debian/patches/00list (or 00list.extensions) to debian/patches.00list.mypatchvariant
  2. enable the patches you would like to use in debian/patches.00list.mypatchvariant by uncommenting/commenting them (keep in mind, that some patches depend on each other and therefore some combination might lead to rejects, that you have to resolve yourself)
  3. PATCHVARIANT=mypatchvariant debian/rules accept-patches
  4. PATCHVARIANT=mypatchvariant dpkg-buildpackage -tc -uc -us -rfakeroot
  5. install the new vdr-dev
  6. build ALL the plug-ins you would like to use

Published on 27/07/2008 at 08:33 by , tags , , , , ,

VDR auf dem EeePC

Das DIV-A VDR-System gibt es schon eine ganze Weile, ist aber erst jetzt auf meinem Radar aufgetaucht, denn das ganze gibt es inzwischen auch für den EeePC. Nicht dass ich so einen mein Eigen nennen würde, aber ich finde die Idee ganz nett. Das ganze baut wohl auf den 1.4'er VDR-Paketen von e-tobi.net auf, die für Xandros adaptiert wurden, und kommt mit HG-Treibern daher. Wer seinen bereits vorhandenen EeePC mit VDR bestücken möchte, für den gibt es eine Installationsanleitung und auch im VDR-Portal gibt es auch einen Thread dazu.

Published on 21/07/2008 at 16:57 by , tags , , , , ,

VDR-Camp 2008

Solange ich noch halbwegs die Augen offen halten kann, möchte ich fix noch meine Eindrücke vom VDR-CAMP 2008 festhalten:

Als powARman und ich am Freitag Abend in Kandel eintrudelten, war schon ordentlich was los. Jede Menge VDR-Hardware und jede Menge (noch) unbekannte Gesichter in einer riesigen Halle.

Auch wenn Kandel nicht unbedingt sehr zentral liegt, der Veranstaltungsort war schon sehr genial - besten Dank an Andreas! Alles war bestens organisiert und es hat an nichts gefehlt, was wohl in erster Linie Michi (skiller2k1) zu verdanken ist, den ich am ersten Tag nur durch die Gegend habe wuseln sehen. Aber Sonnabend war es dann schon etwas entspannter und man konnte sich auch mit Michi mal in Ruhe unterhalten - bis früh um Fünf (weshalb ich heute wohl kaum noch lange die Augen aufhalten kann :-)

Die Vorträge am Sonnabend über DVB-T, VIDEGOR und Xeatre.TV waren ebenfalls sehr interessant (Wer jetzt auf VIDEGOR-Debian-Pakete hofft, wird eventuell auch nicht enttäuscht werden ;-) . Randy hat mit Sicherheit einen Weltrekord im DVB-Karten modden aufgestellt und Dank des guten Wetters hat auch das abendliche Schwenken (=Grillen) richtig Spaß gemacht.

Ohne genau Zahlen zu kennen, schätze ich doch mal, dass sicher 60-70 Leute am Sonnabend anwesend waren - also jede Menge Gelegenheit mit anderen ins Gespräch zu kommen, Anregungen zu sammeln und Ideen auszutauschen.

Am Schluss waren sich auch alle einig, dass es zum VDR-CAMP 2008 unbedingt eine Fortsetzung geben muss. Und wenn es irgendwie geht, bin ich auf jeden Fall wieder dabei!

Danke nochmal an Michi, Andreas und alle anderen die das ermöglicht haben!

Ein paar mehr Bilder gibt es z.B. hier,

Published on 30/03/2008 at 21:40 by , tags , ,

VDR-Pakete mit Unterschrift


Ab sofort sind die VDR-Pakete im e-tobi.net-Repository auch signiert. Damit die Signatur überprüft werden kann, müsst ihr meinen öffentlichen Schlüssel importieren:

gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys DB90D8FC306B6783
gpg --armor --export DB90D8FC306B6783 | apt-key add -

Der erste Befehl importiert den Schlüssel vom keyserver, der zweite teilt APT mit, dass dieser Key vertrauenswürdig ist.

Damit sollte die Meldung "WARNUNG: Die folgenden Pakete können nicht authentifiziert werden!" passé sein.

(Bild: aboutpixel.de © Petra Hager)

[UPDATE 2009-04-19]

Inzwischen ist ein neuer Key mit der Id 0xAEDAA642 im Einsatz. Also:

gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys AEDAA642
gpg --armor --export AEDAA642 | apt-key add -

Oder einfacher:


Published on 25/03/2007 at 23:27 by , tags , , , , , , , ,

Powered by Publify | Photo Startup stock photos