On 12/13/10 11:49, Steffen Barszus wrote: > 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. Of course, but they are *simple* databases ;-) I don't want VDR to become dependent on some particular database software. And I like the fact that these files are plain readable text files. Klaus _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
