[vdr] EPG DB discussion (was Re: Request: E parameter in channels.conf for epg scan)

Steffen Barszus steffenbpunkt at googlemail.com
Mon Dec 13 18:37:56 CET 2010


On Mon, 13 Dec 2010 17:58:50 +0100
Denis Loh <denis.loh at googlemail.com> wrote:

> Am 12.12.2010 22:27, schrieb Eric Valette:
> > On 12/12/2010 22:02, VDR User wrote:
> >
> >> (Btw, Klaus has made it clear VDR was never intended to be a
> >> server/client system.  Maybe at some point it will address that
> >> need in a well-thought out way but as it stands now I'm not so
> >> sure it's a good basis for argument.)
> >
> > On the other hand, with streamdev server, vnsi server, we are 
> > approaching the client server mode.
> >
> > I think the real question for selecting a database are:
> >     1) do I need a SQL interface,
> >     2) do I need a client server model,
> >
> > sqlite is in use in 200MHZ mips router/ Tokyo/Kyoto cabinet can do 
> > less but consume even less.
> I was wondering why it must be a SQL DB. The new VDR requires at
> least one plugin namely sdff- or hdff-plugin So, defining an
> interface - for instance EPGProvider, with a basic implementation
> like the one which already exists - and let the user choose if he
> requires more power and extended functions to store and query the
> EPG, is a good option. Then he may install a EPGProvider plugin which
> comes with a sqlite-DB. Actually, sqlite may be good enough to be
> used for epg data. However I don't see it in the core.

Klaus Point is (until now):
- this wont go into a plugin 
- hand crafted database is enough

My point is:
- i want to have possibility for a choice with difference in
  behaviour/scale

If i remember well the DVB devices have been planned to be plugins as
well in the past - so how the cEIT scanner fits into the picture ? 

I dont want to put something i want down someone elses throat ... only
choice.




More information about the vdr mailing list