[vdr] vdr-kbd eats cpu

[Klaus Schmidinger]

Andre Bischof wrote:
> Andre Bischof wrote:
> ...
> 
>> searched tids ---
>> Jan 15 18:34:03 linux vdr[9709]: video directory scanner thread 
>> started (pid=9709, tid=9710)
>> Jan 15 18:34:03 linux vdr[9709]: video directory scanner thread 
>> started (pid=9709, tid=9711)
>> --- searched tids
>>
>> Jan 15 18:34:03 linux vdr[9709]: probing /dev/dvb/adapter0/frontend0
>> Jan 15 18:34:04 linux vdr[9709]: found 1 video device
> 
> 
> I now did an strace on them:
> 
> strace -ff -F -o vdr-strace.txt ./vdr --config=. --lib=./PLUGINS/lib -d 
> --no-kbd -l 3.6 -p 2001 --video=/video -w 60 -u vdr -g vdr -P remote -P 
> dxr3
> 
> the pids output shows some ENOENTs (file not found), which doesn't seem 
> to disturb vdr, as video/audio are there:
> 
> open("/dev/dvb/adapter0/osd0", O_RDWR)  = -1 ENOENT (No such file or 
> directory)
> open("/dev/dvb/adapter0/video0", O_RDWR|O_NONBLOCK) = -1 ENOENT (No such 
> file or directory)
> open("/dev/dvb/adapter0/audio0", O_RDWR|O_NONBLOCK) = -1 ENOENT (No such 
> file or directory)
> open("/dev/dvb/adapter0/demux0", O_RDWR) = 13
> open("/proc/video/dev/video0", O_RDONLY) = -1 ENOENT (No such file or 
> directory)
> ioctl(4, 0x80a86f3d, 0xbfaa893c) = 0
> open("/dev/dvb/adapter0/ca0", O_RDWR)   = -1 ENOENT (No such file or 
> directory)
> 
> the tids output shows alot entries like this one:
> 
> stat64("/video/14/etc/ssl/certs/ff783690.0", 0x40dffafc) = -1 ENOENT (No 
> such file or directory)
> 
> which comes because a moved a backup copy temporarly to my video dir 
> (space problems). This dir is quite big ~26GB, maybe this is the problem?
> 
> Could it be that every file is scanned in /video to build the record list?
> 
> Ahrg, right at this very moment I read your reply, so moving unnecessary 
> files from /video should do it.

 From VDR's INSTALL file:

Note that you should not copy any non-VDR files into the /videoX directories,
since this might cause the watchdog timer to expire when VDR cleans up those
directories and there is a large number of files and/or subdirectories in
there.

> I also didn't know that -g means grab directory, I thought u and g were 
> user and group :(

Well, it may have been "group" with some patch, but since I believe
-u to set the user should be enough (why wouod you need to set an extra
group?) and I had already implemented the -g option for the GRAB directory,
this is how it is now.

Klaus