On Tue, 14 Dec 2010 10:31:03 +0100 (CET) "Gerald Dachs" <v...@dachsweb.de> wrote:
> > Am 13.12.2010 23:21, schrieb Gerald Dachs: > > > > >> Maybe I understand the code in epg.c wrong, but it look like that > >> the whole epg.data file is always read and write complete by the > >> vdr. Even if only one record has to be changed. Maybe the coding > >> with sqlite will look less elegant, but it will be much faster. > >> I/O is always expensive. > >> > > Afaik the epg.data will be read at startup and written at shutdown. > > In the meantime the epg data will be read from memory and thats > > surely much faster than via sqlite. > > This is true, but not if you update it from an external source, and > this was the reason for this discussion. I didn't start the performance discussion, but ... Agree with you. At the moment my parser needs 16s to parse XML and write it to the file for load. Expecting it not to become significant slower with sqlite3 output, that would mean (if vdr would not use in memory db) one could skip the load process since its submitted already to the vdr DB. For those concerned, putting the DB on a ramdisk, should give the best from both worlds + it could be easily connected from other applications to it. Anyway -> result until now: 1.) Klaus doesnt like it, also does not like to make it possible to do it in a plugin. 2.) Some have a deep hate against any SQL solution. 3.) Some do like the idea - continue on point 1.) Well it was worth a try ... :( _______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
