On Sun, 12 Dec 2010 23:33:13 +0100
Klaus Schmidinger <klaus.schmidin...@tvdr.de> wrote:

> On 12.12.2010 18:21, Steffen Barszus wrote:
> > If we can be sure that between clre and adding the external epg no
> > event comes into vdr by cEIT, means it can be ensured that this
> > holds true for any stations external epg is used. 
> I guess that should be pretty easy to establish.
> Simply blocking any EPG data coming from the transponders for a
> certain time (10 seconds, one minute? you name it) after a CLRE
> command has been received should do it. Once there is an EPG event in
> the schedule that has a table id of 0, that schedule would no longer
> receive any data from the DVB stream (until all its events have timed
> out and no further external events have been supplied, at which time
> it would fall back to the DVB EPG data).

Fine with me :)

> > On a side note to this, slightly OT: 
> > Thinking: What if a plugin could provide the EPG functionality for
> > vdr ?
> EPG is a core feature of VDR (and DVB at large) and as such shall stay
> in the core VDR code. Besides, only the EPG data provided from the DVB
> data stream can support actual running status and thus VPS
> functionality

I didn't say it should be removed - i just wanted alternative
implementation for those wanting it. (no C++ expert!) I thought by e.g.
declaring them as virtual functions, this could be archived. Or some
other way .. i don't know

> > In the long run it might be more useful if a more advanced merge
> > from the different epgs source could happen at submission of the
> > epg. The processing should happen in a seperate thread ( Having
> > external epg for 18 days sums up to approx. 70MB, where vdr runs
> > into emergency exit at the moment, if processed at once.) 
> > Current starting time from DVB might still be interesting, even if
> > external epg is a lot better.
> You don't have to feed the whole 70MB into VDR at once.
> Do it channel by channel, and maybe with one channel day by day.
> That should allow enough time for VDR to keep its main loop
> alive.

guess what i am doing. ;) - i just thought i could get rid of some
workarounds over the time instead of adding more ...

> > Having epg in a DB (sqlite,mysql) might also be nice. 
> Definiteley *no* database in VDR!
> I've said it on many occasions, and I'll repeat it as many times
> as necessary! If you want to handle EPG data in a database, do it
> externally and feed the resulting EPG data into VDR via SVDRP.

channels.conf and epg.data definitly are databases even if you don't
name them as such. 

vdr mailing list

Reply via email to