On Fri, Feb 02, 2007 at 04:05:10PM +0200, Marko Myllymaa wrote: > On Thu, 1 Feb 2007, Kartsa wrote: > > >Marko M?kel? kirjoitti: > >>On Thu, Feb 01, 2007 at 10:18:03PM +0200, Kartsa wrote: > >> > >>>Would it really matter in this case when cpu load was that small? I was > >>>just trying to say that even though there were almost no cpu load vdr > >>>was working sluggish. > >>> > >> > >>Without trying it, it is hard to say. You may be right, the load is so > >>small that the sluggishness can result from some mutex waits or > >>something else that wouldn't stand out in a profiler that measures CPU > >>resources. > >> > >>In any case, you could profile the old and new version of vdr and see if > >>there is any obvious difference. > >> > >I'll have to take that into consideration. I'll have to download the old > >version and all that :) [snip] > Also this newer version does some weird busylooping or whatever from time > to time. Vdr gets all remote codes and buffers them, but just starts > executing them after ~45s. One time it took so long, that I got ssh opened > from other computer to restart vdr, but vdr had recovered. I've experienced this once or twice on my setup (softdevice -vo dfb:mgatv, probably some late vdr 1.3.x, on 900 MHz Celeron with 128 or 256 MB of RAM). I sent a command via SVDRP, and it took something like a couple of minutes for VDR to react. As far as I remember, it wasn't recording anything - only replaying a recording or viewing live stream. This may of course be related to some anomaly of softdevice. In the past 2 years that I've used vdr and softdevice, a few times softdevice has failed to start properly. It would play about 0.5 to 1 frames per second and use very little CPU. Restarting VDR has always helped. Before setting up oprofile, you could attach strace to a running vdr and capture the output to a file for a few seconds. Do this for both the old and the new version of vdr, and see if you can find anything. The output will probably vary between runs, so attempts to use tools like "diff" may be futile. Marko
