On 12/13/10 11:49, Steffen Barszus wrote:
> 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.
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.
vdr mailing list