[vdr] Request: E parameter in channels.conf for epg scan

Pasi Juppo Pasi at Juppo.fi
Fri Dec 17 22:58:00 CET 2010


  On 12/15/2010 10:49 PM, Ville Skyttä wrote:
>  On Wednesday 15 December 2010, Jouni Karvo wrote:
> >
> > I think adding dependencies to outside packages is a burden that
> > should be avoided. There are already many things I need to install
> > separately in order the vdr box to work; kernel, graphics drivers,
> > and xine-lib. Luckily, lirc is now already part of the kernel, and
> > DVB drivers, too; much less hassle than before. This is the right
> > direction to go - not adding more moving parts that need to be
> > installed (with compatible versions).
>
>  I'm not saying anything about the epg data as plain text vs sqlite
>  thing, but would like to note that things are not always that black
>  and white as the above seems to say. In my opinion it does not make
>  sense to reimplement everything that's required just in order to
>  avoid dependencies (but other valid reasons for not using something
>  that's already there might of course exist).

And it's not only to avoid unnecessary wheel inventing but also going 
towards more generic solution of the software itself. If I'm not 
mistaking sqlite would actually help also in multi-instance ("server" 
solution) vdr implementation when each instance would be reading/writing 
from/to same DB but also external tools to read/write epg data way more 
faster than via vdr.

But this depate can go on forever back and forth - probably leading to 
no changes what so ever. Klaus have already decided few posts ago to 
keep the text file based solution. Same goes for standalone-server 
wishes (vdr will not change to server-client system). And same for few 
other features.

That said and with no disrespect to the author of vdr in my opinion it 
starts to be a time to fork vdr and redefine its base + few other 
elements. There are many very talented coders reading this mailing-list 
(+ many others over different vdr related sites) who are developing 
plugins and patches - some being very big. Put sources to accessible 
version control system (almost already existing at place where 
previously unmaintained plugins where brought alive), set up issue 
handling system with roadmaps etc. (like Mantis) and of course set up a 
core team of developers who make decisions what go in and what not. I 
believe this would also speed up the development of the vdr itself 
tremendeously due to much greater man power.

Of course things can remain the same but will we ever see natively 
implemented in vdr:
-_proper_ implementation of server-client solution (centralized records, 
epg etc. without "hacks")
-good looking high res OSD
-good integration to XBMC or similar
-fully redefinable menu system
-channel specific configurability (epg...)
-native ATSC support
-several of the big patches integrated (long list) and configurable
-etc.etc.

If I've not read incorrectly what have been written in this mailing-list 
then the answer is *no*.

Hope to get some active discussion around this and actions as well.

Br, Pasi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.linuxtv.org/pipermail/vdr/attachments/20101217/83c11d22/attachment.htm>


More information about the vdr mailing list