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
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