Basically the larger your epg.data is, the more cpu vdr will take up.
VDR runs the SetEvents and GetMatch functions pretty much each time thru the main loop. These functions are fairly "expensive" to run, because they will traverse the full events/epg data trying to match them up with timers.
--- Stefan Taferner taferner@kde.org wrote:
On Thursday 24 February 2005 20:40, Chris Warren wrote:
Hi all,
I've managed to import EPG data for 2-3 weeks in
advance. The trouble is I
use epgsearch to automatically create timers to
record a couple of series.
This leads me to have around 20 active timers.
It seems that the more timers you have the slower
VDR (1.3.21) becomes. I
normally get "max. latency time 2 seconds" in my
syslog, however when I
have 20 timers, I get "max. latency time 17
seconds". What's causing it to
slow down so much?
I've tried removing all plugins but if I leave the
timers, I still get this
long latency and the OSD becomes really slow.
You could do some profiling with gprof. To that you need to link vdr with -- hmm -- I think gp (read: add -lgp when linking), then run it inside gprof (gprof vdr ....).
--Stefan
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr