running vdr-1.6.0_p1-r1 ~amd64 -- localhost alex # /etc/init.d/vdr start * Preparing start of vdr: * config files ... [ ok ] * Waiting for prerequisits (devices nodes etc.) ... [ ok ] * Starting vdr ... [ ok ] * Waiting for working vdr ... [ ok ] * Errors from /var/log/messages: * Jul 27 07:14:58 localhost vdr: [30965] ERROR (thread.c,224): Permission denied * Jul 27 07:14:58 localhost vdr: [30971] ERROR (thread.c,224): Permission denied * Starting vdr watchdog ... [ ok ] -- And here are the corresponding sections from /var/log/messages: -- Jul 27 07:14:58 localhost vdr: [30941] initializing plugin: xineliboutput (1.0.1): X11/xine-lib output plugin Jul 27 07:14:58 localhost vdr: [30941] [xine..put] cTimePts: clock_gettime(CLOCK_MONOTONIC): clock resolution 0 us Jul 27 07:14:58 localhost vdr: [30941] [xine..put] cTimePts: using monotonic clock Jul 27 07:14:58 localhost vdr: [30941] [xine..put] RTP SSRC: 0x24530532 Jul 27 07:14:58 localhost vdr: [30965] ERROR (thread.c,224): Permission denied -- -- Jul 27 07:14:58 localhost vdr: [30941] starting plugin: remote Jul 27 07:14:58 localhost vdr: [30941] remote: using '/dev/input/event6' Jul 27 07:14:58 localhost vdr: [30941] remote-event6: autorepeat supported Jul 27 07:14:58 localhost vdr: [30968] CAM 3: no module present Jul 27 07:14:58 localhost vdr: [30941] remote-event6: exclusive access granted Jul 27 07:14:58 localhost vdr: [30941] starting plugin: xineliboutput Jul 27 07:14:58 localhost vdr: [30971] Remote decoder/display server (cXinelibServer) thread started (pid=30941, tid=30971) Jul 27 07:14:58 localhost vdr: [30971] ERROR (thread.c,224): Permission denied --
it works if you run vdr as root: /etc/conf.d/vdr: START_VDR_AS_ROOT="YES"
It seems the errors are produced by xineliboutput trying to get a higher priority and switching to round-robin scheduling. As only root can do this we have some possible solutions: 1. Patching xineliboutput to not print the errors as the errors are not-critical. (Is this possible?) 2. Change vdr to keep cap_sys_nice and so is still able to set priorities even if switching from root to unpriviliged user. (See http://vdr-portal.de/board/thread.php?postid=522269) I vote for 1.
Is this still persistent? Which versions are affected?
(In reply to comment #3) > Is this still persistent? Which versions are affected? > I use the version 1.0.5-r1 and the problem is still present : Dec 8 13:54:03 xxxxxx vdr: [10081] ERROR (thread.c,225): Permission non accordée Dec 8 13:54:03 xxxxxx vdr: [10082] ERROR (thread.c,225): Permission non accordée Dec 8 13:54:04 xxxxxx rc-scripts: VDR errors from /var/log/messages: Dec 8 13:54:04 xxxxxx rc-scripts: Dec 8 13:54:03 myhost vdr: [10081] ERROR (thread.c,225): Permission non accordée Dec 8 13:54:04 xxxxxx rc-scripts: Dec 8 13:54:03 myhost vdr: [10082] ERROR (thread.c,225): Permission non accordée
This has been fixed in vdr-xineliboutput-9999, please test if possible. I'll try to fix 1.0.5 too ASAP.
(In reply to comment #2) > It seems the errors are produced by xineliboutput trying to get a higher > priority and switching to round-robin scheduling. > As only root can do this we > have some possible solutions: > 1. Patching xineliboutput to not print the errors as the errors are > not-critical. (Is this possible?) Not directly, messages are generated in vdr thread.c. This has been fixed upstream: http://xineliboutput.cvs.sourceforge.net/viewvc/xineliboutput/vdr-xineliboutput/frontend_svr.c?r1=1.99&r2=1.101&view=patch http://xineliboutput.cvs.sourceforge.net/viewvc/xineliboutput/vdr-xineliboutput/tools/udp_pes_scheduler.c?r1=1.54&r2=1.56&view=patch http://xineliboutput.cvs.sourceforge.net/viewvc/xineliboutput/vdr-xineliboutput/tools/sys_cap.h?revision=1.1&content-type=text%2Fplain It will be included in 1.0.6 too. > 2. Change vdr to keep cap_sys_nice and so is still able to set priorities even > if switching from root to unpriviliged user. (See > http://vdr-portal.de/board/thread.php?postid=522269) That's included in vdr-1.7.x
I can't test with vdr-xineliboutput-9999 because this version is very unstable on my system but I've tested version 1.0.6 and i don't have the error messages anymore. I use the ebuild of the version 1.0.5 (the ldflags patch has been added upstream).
Has this been fixed and tested since 2011?
This issue was fixed since version 1.0.6 and version 1.1.0 is in portage now (since January this year).
Thanks guys.
