Re: [vdr] EPG DB discussion (was Re: Request: E parameter in channels.conf for epg scan)
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. --eric ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG DB discussion (was Re: Request: E parameter in channels.conf for epg scan)
On Mon, 13 Dec 2010 17:58:50 +0100 Denis Loh denis@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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] EPG DB discussion (was Re: Request: E parameter in channels.conf for epg scan)
On Sun, 12 Dec 2010 10:24:31 -0800 VDR User user@gmail.com wrote: On Sun, Dec 12, 2010 at 9:46 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Having epg in a DB (sqlite,mysql) might also be nice. You are going to find a lot of opposition to this. Thinking of sql, I don't recall ever hearing anyone suggest VDR using it would be a good idea but I have heard people will look into other options if it ever did go that route (as mythtv uses currrently). That is why Steffen wrote to make it a plugin. EPG support falls into the category of the most basic functionality. I'm not convinced things like this belong as optional plugins to be honest. Some things, such as VDR's attachment to FF cards, make sense as plugins. But it seems the automatic answer to everything is 'make it a plugin' now. So is VDR to become merely a plugin manager with no actual core functionality anymore? Is it wise to have VDR rely on plugins to be usable at all? These types of questions deserve consideration when you want to walk on slippery slopes. I strongly believe that there is a way to make it possible to replace/extend core functionality by a plugin - i can see that not everybody might want what i would imagine to be perfect. Still i did not wrote mysql alone, my thought was sqlite for normal use, and a real db (rather postgre ?) for networked/client-server use. sqlite i could imagine even in core - making the connection sql - mysql - mythtv - bad , doesn't have any substance at all. And talking about people who would leave vdr for the reason of what i'm talking about doesn't add anything either. I daily load a full set of epg from an external source, for the statistics: 70MB EPG data, containing 102.006 records, loaded daily. Extended by VDR-Seriestimer.pl called by epgsearch at the time of creating a timer. Wanting to say it can be easy or can have any complexity you want, for the latter, vdr current epg handling doesnt scale so well ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG DB discussion (was Re: Request: E parameter in channels.conf for epg scan)
On Sun, Dec 12, 2010 at 11:14 AM, Steffen Barszus steffenbpu...@googlemail.com wrote: sqlite i could imagine even in core - making the connection sql - mysql - mythtv - bad , doesn't have any substance at all. And talking about people who would leave vdr for the reason of what i'm talking about doesn't add anything either. I wouldn't be so quick to disregard user opinion. I think it's important to consider what people think who are using sql in a similar way. Do you honestly believe their first-hand experience in this area is meaningless, and that all the complaints about it with virtually nobody suggesting its a great idea is mere worthless chatter? There's a reason sql is unpopular. It's unfortunate you think that has no value and should be disregarded. It seems you think anything or any opinion that doesn't support the idea simply 'doesn't add anything'. I know a whole lot of users who will disagree with you on that. There are also other options that could be explored as well - and should be if there's to be any changes made. (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.) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG DB discussion (was Re: Request: E parameter in channels.conf for epg scan)
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. --eric ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
