[mythtv-users] Image ghosting on 0.24

[Andre]

I seem to have an intermittent problem with Mythfrontend since upgrading to 0.24.

I have a master backend and slave backend/ frontend system, most content is 1080i H264 from satellite, BBC, ITV HD etc.
Currently Ubuntu 10.04 32bit on be & fe, 0.24 from JYA's repo (so trunk(ish) currently)

MythTV Version   : es27396
MythTV Branch    : trunk
Network Protocol : 63
Library API      : 0.24.20101129-1
QT Version       : 4.6.2
Options compiled in:
 linux debug using_alsa using_jack using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_directfb using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

Possibly the initiator of the problem; I get playback pauses/hiccups, this is co-incident with a blast of h264 errors in the FE log, yet often these errors are logged and no pauses are seen.

I am using a GT220 with Adv 2x deint and ivtc, this has been excellent with 0.23 on the same hardware, fe is a 1.8Ghz C2D clocked at 1Ghz. I upgraded to 0.24 to resolve some ac3 audio problems, btw ac3 now works perfectly :-P

For example, sometimes at this rate for the duration of the show.

2010-11-07 13:42:50.173 [h264_vdpau @ 0x4df5960]non-existing SPS 32 referenced in buffering period
2010-11-07 13:42:50.174 [h264_vdpau @ 0x4df5960]non-existing SPS 32 referenced in buffering period
2010-11-07 13:42:50.174 [h264_vdpau @ 0x4df5960]non-existing SPS 32 referenced in buffering period
2010-11-07 13:42:50.174 [h264_vdpau @ 0x4df5960]non-existing SPS 32 referenced in buffering period
2010-11-07 13:42:50.174 [h264_vdpau @ 0x4df5960]non-existing SPS 32 referenced in buffering period
2010-11-07 13:42:50.174 [h264_vdpau @ 0x4df5960]non-existing SPS 32 referenced in buffering period
2010-11-07 13:42:50.212 [h264_vdpau @ 0x4df5960]non-existing SPS 32 referenced in buffering period
2010-11-07 13:42:50.212 [h264_vdpau @ 0x4df5960]non-existing SPS 32 referenced in buffering period
2010-11-07 13:42:50.252 [h264_vdpau @ 0x4df5960]non-existing SPS 32 referenced in buffering period

I have been able to reduce pauses significantly by FE logging to /dev/null but of course this doesn't help debug the problem. Verbose logging prevents the FE from functioning usably, these log entries were there in 0.23 but not so numerous.

The problem will start after one of these pauses, from then onwards all motion has a ghost effect following after, a little like comet trails on a tube camera but short lived, only 3 or 4 frames in duration. Once in this state all recordings show the problem, all of the time, it can sometimes be resolved by dropping to MythWelcome and re-starting the FE, other times unloading and reloading the nvidia module is required or a reboot.

Note: the problem state does not occur in the same place in the recording when watching again and if I watch the same recording on my Mac laptop it plays fine.

This is what I have tried so far:

The FE was originally Ubuntu 10.10 with nvidia 260.19.21 running from a local laptop disk, I reverted to an older 10.04 netboot image with nvidia 256.x.x drivers, and brought this up to 0.24 exactly as the backend. This has changed the problem subtly, it still occurs, triggered and cleared in the same manner but is visually much less pronounced.

Note: possibly significant, when downgrading to the 10.04 netboot image I was unable to start the FE (OGL error) until starting with -O to force qt theme rendering. I had this same error on the Master BE but solved it by upgrading to Nvidia 260.

This issue has persisted through the last three or four repo updates, perhaps more as I have been abroad most of the time since the upgrade to 0.24 (so recording not watching). Due to the large number of recordings made while I was away I'd rather not revert to 0.23, I'm more likely to use a PS3 or laptop hooked up to TV to playback until I can find a solution.

It "smells" like an Nvidia bug but triggered by something that changed in 0.24, possibly post 0.24-fixes.

My next step I think would be to change to Mythbuntu 0.24 builds and see if the problem persists but other suggestions are welcomed.

Andre