Lange hat es gedauert, aber hier kommt nun endlich der erste Teil der Auswertung zur VDR-Plugin-Umfrage 2008.

Beteiligt haben sich 570 VDR-Nutzer. Davon haben nur 493 Nutzer auch die Plugins bewertet. Im ersten Teil der Umfrage ging es um den VDR im Allgemeinen.

Sorry for letting you wait so long for the results of the VDR Survey.

Part one of the survey analysis is nearly done and coming soon. Please be patient!

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

http://e-tobi.net/survey/

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!

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.

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

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.

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,

As announced earlier I’ve updated the vdr-experimental repository with the VDR 1.5.14 packages.

The following plug-ins have been dropped due to lack of upstream support:

• autotimeredit (Letzte Version von 11/2005)
• console (Letzte Version von 09/2004)
• mediamvp (Letzte Version von 04/2005)

The subtitles plug-in isn’t necessary anymore. DVB subtitles are now directly supported in VDR.

The following plug-ins don’t work at the moment: * channelscan * reelchannelscan

To use the pvr350 plug-in with Etch, you need to update the Kernel. The kernel packages available at backports.org will work.

All packages are available for the i386 and the amd64 architecture.

An update to VDR 1.5.14, which was released today, will follow soon.

Tobias

There hasn’t been very much happening in the repository lately, so I decided to do some early spring-cleaning. The VDR 1.4.7-packages in the vdr-experimental repository seem to be pretty stable, so I will move the Etch packages from vdr-experimental to vdr-testing. In vdr-testing there will only be minor updates like important bug fixes in the future. So whoever is currently running happily on vdr-experimental / Etch, should update his sources.list to point to vdr-testing:

#
# e-Tobi's Testing Etch VDR Repository
#
deb http://e-tobi.net/vdr-testing etch base backports addons vdr-standard
#deb http://e-tobi.net/vdr-testing etch base backports addons vdr-multipatch
#deb http://e-tobi.net/vdr-testing etch base backports addons vdr-extensions

vdr-experimental will soon be updated to VDR 1.5.x / VDR 1.6. To stay up-to-date with the latest VDR and plug-in version, use this repository entry:

#
# e-Tobi's Experimental Etch VDR Repository
#
deb http://e-tobi.net/vdr-experimental etch base backports addons vdr-standard
#deb http://e-tobi.net/vdr-experimental etch base backports addons vdr-multipatch
#deb http://e-tobi.net/vdr-experimental etch base backports addons vdr-extensions

vdr-experimental also provides packages for Debian Sid:

#
# e-Tobi's Experimental Sid VDR Repository
#
deb http://e-tobi.net/vdr-experimental sid base backports addons vdr-standard
#deb http://e-tobi.net/vdr-experimental sid base backports addons vdr-multipatch
#deb http://e-tobi.net/vdr-experimental sid base backports addons vdr-extensions

The old Sarge packages (VDR 1.2.6, 1.4.4 and 1.4.6) are not maintained anymore, so I moved them to vdr-deprecated:

#
# e-Tobi's Old Sarge VDR Repository (will soon be dropped!)
#
deb http://e-tobi.net/vdr-deprecated/vdr-stable sarge base backports addons vdr-standard
#deb http://e-tobi.net/vdr-deprecated/vdr-stable sarge base backports addons vdr-multipatch
#deb http://e-tobi.net/vdr-deprecated/vdr-testing sarge base backports addons vdr-standard
#deb http://e-tobi.net/vdr-deprecated/vdr-testing sarge base backports addons vdr-multipatch
#deb http://e-tobi.net/vdr-deprecated/vdr-experimental sarge base backports addons vdr-standard
#deb http://e-tobi.net/vdr-deprecated/vdr-experimental sarge base backports addons vdr-multipatch

For some reason Mplayer can't stream the Quicktime versions of Galacticast. I think, it's the advertisements that blip.tv tries to send, which cause it to fail. VLC doesn't work either. So please update your vodcatchersources.conf to:

FEED_URL=http://feeds.feedburner.com/galacticast-wmv