Difference between revisions of "VDR"

From LinuxTVWiki
Jump to: navigation, search
(VDR source code repository)
Line 34: Line 34:
 
You can use 1.0, 1.2. 1.4 for old stable versions too.
 
You can use 1.0, 1.2. 1.4 for old stable versions too.
  
There are more git-based VDR plugin projects at
+
A copy of the VDR developer git repo and some git-based VDR plugin projects can be found here:
 
  http://projects.vdr-developer.org/projects
 
  http://projects.vdr-developer.org/projects
  
Line 40: Line 40:
  
 
Hopefully the use of git will continue to increase and the VDR community will become less tolerant of the patch madness that has been prevalent for so long.
 
Hopefully the use of git will continue to increase and the VDR community will become less tolerant of the patch madness that has been prevalent for so long.
 +
 +
==TODO list==
 +
or, what needs to happen coz it's the freakin' 21st century already:
 +
* convince Klaus to use a public source code repository, and to accept and commit patches
 +
* bring all the (living) plugins into a _single_ git repo (give commit permissions to their respective authors/maintainers)
 +
* set up a single standard (autoconf) build system for all the plugins (select which ones to compile with ./configure --with-[x] options). _This_ is where you do version checking to make sure it all works.
 +
* deprecate all the non-committed patches and scripts (i.e. commit them or kill them)
 +
 +
 +
 +
 +
 +
  
 
== External Links ==
 
== External Links ==

Revision as of 14:38, 9 July 2009

Video Disk Recorder Project, initiated by Klaus Schmidinger, which makes your PC a "full-featured" SetTopBox. Requires one of:


Here are some details about using VDR with Multiproto Multiproto#Tuner_.2F_DiSEqC_.2F_Player_support.

VDR source code repository

Recently there has been renewed talk on the VDR mailing list of creating a source code repository, so bringing VDR into line with almost all major open source projects, which use repositories such as git or mercurial to keep track of the many source code updates. See http://linuxtv.org/pipermail/vdr/2008-September/017659.html. The original developer of VDR has so far been hesitant to agree, but developers point to a hiatus of 144 days in development and the exodus of users from the VDR camp (mostly to MythTV) as a reason to modernise the software development process.

As with many personal projects which have reached a certain size there is a choice to be made: either advance and become a modern open-source bazaar-style project with everything that entails (source repository, maintainer hierarchy, release schedule, good regular communication), or don't change and be continue to be overtaken in mind-share by other better-run projects which better satisfy a large community of users and developers. See http://www.linuxtv.org/pipermail/vdr/2009-January/019185.html.

A read-only git repository has now been created containing the main releases. This makes it easy for community members to create their own VDR developer trees (by cloning) for management of code and merging of changes. See http://www.linuxtv.org/pipermail/vdr/2008-September/017769.html.

VDR developer:

git clone git://vdr.gekrumbel.de/vdr.git

VDR stable:

git clone git://vdr.gekrumbel.de/vdr.git stable/1.6

You can use 1.0, 1.2. 1.4 for old stable versions too.

A copy of the VDR developer git repo and some git-based VDR plugin projects can be found here:

http://projects.vdr-developer.org/projects

Unfortunately no public repository is being actively used for development of VDR on a patch-by-patch basis. The commits to the git repository are giant code bombs which mirror the tar files on the VDR homepage. This means that the (valuable) granularity of individual patches (and descriptions of them) is not available.

Hopefully the use of git will continue to increase and the VDR community will become less tolerant of the patch madness that has been prevalent for so long.

TODO list

or, what needs to happen coz it's the freakin' 21st century already:

  • convince Klaus to use a public source code repository, and to accept and commit patches
  • bring all the (living) plugins into a _single_ git repo (give commit permissions to their respective authors/maintainers)
  • set up a single standard (autoconf) build system for all the plugins (select which ones to compile with ./configure --with-[x] options). _This_ is where you do version checking to make sure it all works.
  • deprecate all the non-committed patches and scripts (i.e. commit them or kill them)




External Links