VDR Plugin Survey 2008 - Auswertung Teil 1

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.

VDR-Nutzung

80% der Umfrageteilnehmer (457) haben angegeben, den VDR auf einem separaten Rechner zu betreiben.

Etwas mehr als die Hälfte der Teilnehmer begnügt sich mit einem VDR-System, während ein Viertel schon zwei VDR’s im Einsatz hat. Immerhin mehr als 10 Prozent haben sogar drei VDR Systeme, 5% haben vier oder fünf und zwei Power-User sind sogar Herr über 6 und 7 VDR’s.

number of vdr systems in use

DVB-Typen / Empfangsquellen

Was nicht verwundert: Bei den Empfangsarten hat DVB-S(2) ganz klar die Nase vorn. Dass DVB-T und DVB-C in etwa gleich auf liegen, hätte ich jedoch nicht erwartet. (Was aber wohl in erster Lienie daran liegt, dass in meiner Gegend einfach kein vernünftiger DVB-T-Empfang möglich ist). Immerhin 7% der Befragten haben angegeben, auch Online-Quellen (IPTV) zu verwenden.

number of vdr systems in use

Am gebräuchlichsten scheint die Kombination DVB-S / DVB-T zu sein.

number of vdr systems in use

Distributionen

Hier muss vielleicht vorweg festgestellt werden, dass die Umfrage diesbezüglich eventuell etwas stärker in Richtung Debian / c’t VDR tendiert, da viele Nutzer des e-tobi.net-Debian-VDR-Repositories u.U. eher dazu bereit waren, an dieser Umfrage teilzunehmen.

Hier die VDR-“Marktanteile” der Top-Ten-Distributionen:

number of vdr systems in use

Die “Major Players” scheinen hier vor allem Debian/Ubuntu/c’t-VDR (diese drei verwenden mehr oder weniger exakt die selben VDR-Pakete), EasyVDR und Gentoo/Gen2VDR zu sein.

Die komplette Liste der Nutzerzahlen pro Distribution finder ihr in diesem OpenOffice-Dokument. Zu Beachten ist, dass es bei einigen Distributionen, wie z.B. bei ctvdr und Debian, Überschneidungen gibt, wenn eine Distribution nur eine Spezialisierung der anderen ist.

Betrachtet man die Anzahl Nutzer, die VDR und/oder Plugins selber compilieren, so schneiden reelbox und mld, mit einer allerdings nicht sehr aussagekräftigen Nutzerzahl, am besten ab. Dort muss niemand etwas selber compilieren.

Bei den Distributionen mit etwas breiterer Nutzerbasis, liegt LinVDR in Führung. Hier fanden nur 17% der Nutzer, dass LinVDR ohne eigene Anpassungen ihren Anforderungen genügt. Bei c’t-VDR ist es ein Viertel der Nutzer, denen die angebotenen Pakete nicht ausreichen, bei EasyVDR und Gen2VDR ist es etwa ein Drittel. Die genauen Zahlen, auch für die anderen Nutzer, findet ihr diesem OpenOffice-Dokument.

Die Gründer aus denen jemand sich entscheidet, den VDR selber zu compilieren, anstatt die vorgegebenen Paket zu verwenden, sind u.A. die damit verbundene Flexibilität und die Möglichkeit auch Details kontrollieren zu können. Oft sind aber auch die angebotenen Pakete zu alte oders es fehlen Plugins und Patches. Nicht zuletzt spielt aber auch der Spaß am Selbermachen für viele eine Rolle.

Eine Übersicht der Kommentare mit Zuordnung zu den jeweiligen Distributionen gibt es hier

Allgemeine Anmerkungen zum VDR

In den 145 freien Kommentaren kommt überwiegend nur positives zum Ausdruck - besonders von den Langzeitnutzern, die den VDR schon seit Jahren nutzen. Sehr viel negatives ist hier aber auch nicht zu erwarten, denn wer den VDR nicht mag wird mit aller Wahrscheinlichkeit auch nicht an der Umfrage teilnehmen. Hier ein paar Auszüge:

Excellent application, I’ve been using it since 2003 IIRC

Changed my way to consume TV forever :)

Love it :) I try MythTV now and again, but it’s a huge oaf and I always come back to VDR.

it rocks :)

Very nice peace of software and I’m using it for about 6 years now

I couldn’t bear to be without VDR anymore!

it’s easy and it’s fun

Respekt in erster Linie an Klaus und auch alle die Ihr Zeit für VDR opfern.

great!!! waf >= 100%

Es ist ein geiles Hobby. Ich wünschte, ich hätte mehr -zeit -verstand -geld für hardware Ich hoffe, vdr wird nie fertig!

Geniale Software. Hat bei mir den klassischen Fernseher im Wohnzimmer ersetzt.

I am not the first to say so and hopefully not the last, but this is one of the greatest projects I ever came upon. I use it now for 5 years, I think 1.1.26 was the version I started with and I do hope for many years to come.

beste Erfindung seit geschnitten Brot ;-))

Aber es gab auch ein paar kritische Anmerkungen und Wünsche. Viele warten auf HD-Unterstützung:

Yes I’d like to see more work done in the direction of HD and Soft Decoders. As great as the Nexus-x is, it’s time to move on. Barring that anything that can be done to make the upcomming TT-S2 6400 as eays to use as the cuurent Nexus-x would be just as useful for me

Waiting for HDTV/DVB-S2/H264 support in prebuild packages.

Die Einfachheit und Stabilität vom VDR wird oft gelobt, ist aber auch Kritikpunkt:

Better media playing functionalities and support for modern software based UI would be great. The UI looks old and ugly but it is highly functiona

Einige Leute sind über die lansgame Entwicklung besorgt:

vdr is nice and stable. However it’s a very limited peace of software. I can’t wait to see it being forked ! Klaus just have simple needs. vdr architecture needs a lot of reworking to handle more complex needs/setups. I’d like to see a public repository and a lot more people able to commit. channels handling is very basic and limited ! some patches are need when you have a complex dish+cards setup. you need to run 2 vdr instances (+streamdev) if you have a multiple card setup and want to have independant frontend+osd.

Weiterentwicklung wird leider spürbar langsamer

need more development like in past years :(

Ein Liste mit allen Kommentaren zum VDR gibt es hier.

Tags ,

Posted in | Posted on 16 Nov 2008 15:44by Tobi | 1 comment

VDR Plugin Survey 2008 - Results coming soon!

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!

Tags ,

Posted in | Posted on 14 Oct 2008 02:15by Tobi | no comments

VDR Plugin Survey 2008

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!

Tags , ,

Posted in | Posted on 31 Aug 2008 14:08by Tobi | no comments

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.

Tags , ,

Posted in | Posted on 10 Aug 2008 00:03by Tobi | no comments

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

Tags , , ,

Posted in , | Posted on 27 Jul 2008 08:33by Tobi | no comments