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