On Sun, 12 Dec 2010 23:33:13 +0100 Klaus Schmidinger <Klaus.Schmidinger@xxxxxxx> 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 vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
