On 12.12.2010 18:21, Steffen Barszus wrote: > On Sun, 12 Dec 2010 16:19:00 +0100 > Klaus Schmidinger <Klaus.Schmidinger@xxxxxxx> wrote: > >> On 09.12.2010 07:59, Steffen Barszus wrote: >>> On Wed, 08 Dec 2010 23:22:05 +0100 >>> Klaus Schmidinger <Klaus.Schmidinger@xxxxxxx> wrote: >>>> On 08.12.2010 20:25, Jochen Dolze wrote: >>>>> To be able using other epg sources with other event ids as from >>>>> the broadcaster. Today i cannot add 14 days of external epg >>>>> without patching. >>>> >>>> Why would you have to patch VDR for that? >>>> External event's by default have a "table id" if 0, which means >>>> they will never be overwritten by data from the transponder. >>> >>> You will get duplicate EPG entries if the time doesn't match >> >> Hmm, I see. >> So how about changing cEIT in such a way that it never overwrites >> any events in a schedule if the first existing event in that schedule >> has a table id of 0? > > 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). > 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 > 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. > 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. Klaus _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
