[solved] high CPU usage for VDR

Apologies if this problem has been described before, but my German is a bit rusty, so it's a bit hard to search the boards.

I've been running yavdr instead of my old homecooked VDR setup for about a week, and have ironed out a few quirks. However, it seems that VDR is using a lot of CPU, and I can't seem to find any reason for it. I'm running with xineliboutput plugin and vdpau. Here's the output of top;

top - 22:41:36 up 1:51, 3 users, load average: 6.22, 6.41, 6.34
Tasks: 124 total, 1 running, 123 sleeping, 0 stopped, 0 zombie
Cpu(s): 33.9%us, 63.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 2.5%hi, 0.6%si, 0.0%st
Mem: 1544120k total, 762368k used, 781752k free, 241720k buffers
Swap: 4523000k total, 0k used, 4523000k free, 155840k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2615 vdr 10 -10 402m 35m 10m S 78.3 2.4 13:54.38 vdr
2705 vdr 10 -10 171m 50m 13m S 20.0 3.4 3:37.15 vdr-sxfe
2060 root 20 0 2544 1192 904 S 0.3 0.1 0:06.15 top
[...]

Is there a plugin running by default which might cause high cpu usage?

Am running yavdr 0.3a updated to latest with apt-get dist-upgrade.

Zitat

Originally posted by gda
You forgot to describe the hardware. Hopefully you are not using the default iptv channels anymore?

No, only DVB-T (Australia). I've got two nova-t 500 cards in a box with an Aopen i915Ga-HFS motherboard with a pentium M 1700MHz processor with a geforce 9500 gfx card. vdr-sxfe cpu usage is not low with this processor, even with vdpau, but has proven sufficient with my homegrown vdr setup in the past.

Unfortunately, I've been using Fedora and other redhat based distros in the past, so am a bit new to ubuntu and how to patch and recompile packages.

Zitat

Originally posted by TomJoad
top -H -b -n1 might give the vdr-thread with highest usage

I guess this is the root of the problem. What does those video directory processes do? Have included the output of mount below.

root@ubuntu:~# top -H -b -n1
top - 20:21:50 up 8 min, 3 users, load average: 6.56, 5.11, 2.40
Tasks: 193 total, 6 running, 187 sleeping, 0 stopped, 0 zombie
Cpu(s): 31.3%us, 37.6%sy, 0.4%ni, 0.3%id, 24.2%wa, 4.1%hi, 2.1%si, 0.0%st
Mem: 1544120k total, 885908k used, 658212k free, 231832k buffers
Swap: 4523000k total, 0k used, 4523000k free, 211348k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1990 vdr 10 -10 437m 41m 10m R 35.1 2.8 1:19.85 video directory
1989 vdr 10 -10 437m 41m 10m R 34.1 2.8 1:19.85 video directory
2044 vdr 10 -10 177m 53m 13m S 11.4 3.5 0:58.27 vdr-sxfe
2043 vdr 10 -10 177m 53m 13m S 2.1 3.5 0:04.96 vdr-sxfe
2045 vdr 10 -10 177m 53m 13m S 2.1 3.5 0:03.71 vdr-sxfe
2061 vdr 10 -10 437m 41m 10m S 1.0 2.8 0:02.92 recording
2062 vdr 10 -10 437m 41m 10m S 1.0 2.8 0:02.64 receiver on dev
2070 vdr 10 -10 437m 41m 10m S 1.0 2.8 0:03.61 recording
2041 vdr 10 -10 177m 53m 13m S 1.0 3.5 0:44.75 vdr-sxfe

/dev/sdc2 on / type ext4 (rw,errors=remount-ro)
[...]
/dev/sda4 on /mnt/fc12 type ext3 (rw)
/dev/mapper/video_volume_group-videolv on /video type ext4 (rw)

Zitat

Originally posted by andreash
Ah, had the same issue lately, where I had linux kernel sources in the video directory (for lack of space on the root disk).

There are two other possible causes for long running video directory scanner threads:
1. different time on the client and server, when the video dir is mounted via network
2. the .update file in the video dir is frequently touched. this causes an immediate run of these threads.

None of these applies to my case, nor have I put any unrelated files into the vdr video directory.

I do see some very long file names though, this shouldn't be any concern? Eg.

/srv/vdr/video.00/Glee/Concerned_that_Sue_is_up_to_no_good,_Will_pays_a_visit_to_the_instructor_of_a_competing_Glee_Club_to_see_what_information_she_might_be_leaking._Meanwhile_Kurt_gives_Rachel_a_makeover_to_impress_Finn./2010-12-27.19.28.10-0.rec

Also, I cannot see any info from VDR in /var/log/messages about it starting any video directory threads, which is normally shown. Is there no log configured for vdr in yavdr?

I found the problem. Somehow a symbolic link had been added in /srv/vdr/video.00;

lrwxrwxrwx 1 vdr plugdev 9 2010-12-27 20:46 FC11 -> /mnt/fc12/

Ie. a symbolic link to my other disk volume, which contains a full linux installation.

I assume this is due to some logic in yavdr that it automatically adds mounted disks so that VDR will find recordings on them. I guess some sort of logic where it would detect if a mounted volume is indeed a VDR disk / directory or not.