On Mon, 13 Dec 2010 12:14:48 +0100 Klaus Schmidinger <Klaus.Schmidinger@xxxxxxx> wrote: > 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. As allready stated - i thought that there is a way to replace in-vdr-functionality by a plugin implementing the necessary methods. Where i see the use of sqlite is that only parts of the data can be manipulated while vdr is running, user defined manipulations for epg bug fixing could happen as well, as possibly some relation between external epg and DVB events could possibly be implemented in the future or merging epg events from DVB with informations from somewhere else (speak eplists, http://thetvdb.com/). Furthermore the synchronization between different applications using the epg (i.e. XBMC) could be omitted since read access would still be possible. AND if the interface is abstract enough, having a real DB (postgre?) could help for client server environments having one EPG DB shared between all clients, not sending hundreds of MB around the local network for something simple like the EPG of "just a video disc recorder". Right now you would need to fetch the epg from the outside, from vdr , try to merge it , pumping it back in pieces suitable for vdr to not influence user experience by blocking the main loop. This is some high level debating on thoughts about vdr - lets see what Jochen thinks of your proposal ... _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
