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

Andrey Vlassov andreyv at ece.ubc.ca
Fri Dec 17 23:45:36 CET 2010


Dear Pasi,

it is a great idea to fork a new line and rewrite code to satisfy all 
requests which been put forward.

Please let me know when you will set a repository and write stable code 
so that I could give it a try. Please make changes quick so that people 
who was waiting for this changes had a chance to have better software.

You will be our hero.

NOTE: many demand but few commit time and do it.

Thank you,
Andy

On 17/12/10 1:58 PM, Pasi Juppo wrote:
> 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
>
>
> _______________________________________________
> vdr mailing list
> vdr at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.linuxtv.org/pipermail/vdr/attachments/20101217/70863c7e/attachment.htm>


More information about the vdr mailing list