[vdr] Request: E parameter in channels.conf for epg scan
andreyv at ece.ubc.ca
Fri Dec 17 23:45:36 CET 2010
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.
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
> >> 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
> > thing, but would like to note that things are not always that
> > 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
> > avoid dependencies (but other valid reasons for not using
> > 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vdr