On Wed, 2008-08-13 at 16:39 +0200, Thomas Hilber wrote:
And now.. part 2 :)
- stop drift_control
- unload all dvb modules (there are known issues with some)
- start vdr with local sxfe frontend (make channels.conf zero size file)
- start replay of some recording. Because field polarity is not synced
automatically anymore you can manually restart replay until polarity is correct.
OK, found a suitable recording, and after a couple of 'play 1 begin' to SVDRP it starts OK. The picture is pretty good, but it still shifts around the screen a bit:
drift speed: 982 overall compensation: 30 sync point displacement: 1118 drift speed: 422 overall compensation: 53 sync point displacement: 64 drift speed: -916 overall compensation: -29 sync point displacement: 613 drift speed: -282 overall compensation: 11 sync point displacement: -216 drift speed: -369 overall compensation: -20 sync point displacement: -499 drift speed: 163 overall compensation: -11 sync point displacement: -685 drift speed: 393 overall compensation: -10 sync point displacement: 3175 drift speed: 8509 overall compensation: 402 sync point displacement: 6186 drift speed: -13504 excessive drift speed overall compensation: -252 sync point displacement: -846 drift speed: -4863 overall compensation: -196 sync point displacement: -430 drift speed: 7566 overall compensation: 246 sync point displacement: -438 drift speed: -8988
So, wow yes it's still all over the place :(
FWIW, the output is not once per second.. there is often a delay of up to 4 seconds before another group of 3 lines is displayed.
If the 'drift speed' value finally does show large deviations from zero this could be a problem in your xine-lib. In that case I upload my current xine-lib version to my web server.
Ouch.
I tried first with the xine-lib 1.11.1 which ships with ubuntu hardy, and then forward-ported the 1.1.7 packages from gutsy (whilst repackaging the xineliboutput support for 1.1.7) and had exactly the same problem. I just find it a bit strange that the same problem should manifest itself with both an older and a newer xine-lib than you use (listed as 1.1.8 in your original post)
So, I started looking for other reasons. Whilst X + vdr are running, the Xorg process is taking 40% CPU, with vdr taking 25%. The 'system' CPU usage is 32%, with 16% for user processes. I thought maybe it was using X11 output rather than xv, and thus causing a drain on the system...
I have executed 'xhost +' to eliminate X security issues... and the syslog shows all positive output:
starting plugin: xineliboutput Local decoder/display (cXinelibThread) thread started (pid=14236, tid=14242) [xine..put] xineliboutput: plugin file is /usr/lib/vdr/plugins/libvdr-xineliboutput.so.1.6.0 [xine..put] Searching frontend sxfe from /usr/lib/vdr/plugins/ [xine..put] Probing /usr/lib/vdr/plugins/libxineliboutput-sxfe.so.1.0.0rc2 [xine..put] load_frontend: entry at 0xb569a154 [xine..put] Using frontend sxfe (X11 (sxfe)) from libxineliboutput-sxfe.so.1.0.0rc2 [xine..put] cXinelibLocal::Action - fe created [vdr-fe] sxfe_display_open(width=720, height=576, fullscreen=1, display=:0) [vdr-fe] Display size : 190 x 152 mm [vdr-fe] 720 x 576 pixels [vdr-fe] 96dpi / 96dpi [vdr-fe] Display ratio: 3789.000000/3789.000000 = 1.000000 [vdr-fe] Failed to open connection to bus: Failed to execute dbus-launch to autolaunch D-Bus session [vdr-fe] (ERROR (gnome_screensaver.c,55): Resource temporarily unavailable) [xine..put] cXinelibLocal::Action - fe->fe_display_open ok [xine..put] cXinelibLocal::Action - xine_init [vdr-fe] fe_xine_init: xine_open_audio_driver("alsa:default") failed [xine..put] cXinelibLocal::Action - fe->xine_init ok [xine..put] cXinelibLocal::Action - xine_open
'xvinfo' shows all the good stuff (pages of capabilities), too.
So I'm not entirely sure where to take it from here. Clearly it can work, but I must be missing a piece..
Sorry - it's a bit of a mixed bag response - I was hoping it would be much more clear cut!
Cheers, Gavin.