VDPAU initialization fails displaying old frame buffer information on watch recording

[databubble]

I have two VDPAU front-end systems (an IGP8200 chipset motherboard, and a Zotac ION) both running trunk and nVidia 190.36 driver which exhibit the same behaviour. When initializing the video to watch a recording, frequently (more often then not) instead of the video displaying, Myth will show old frame-buffer information. Frequently, an intact screen from setup is shown. Sometimes it's a garbled collage of old images from a separate web browser, etc.

The displayed screen is static, but the sound from the video can be heard. Also, pressing 'w' (screen zoom options) immediately restores the proper video stream.

The recordings are being captured by an HD-PVR.

I've seen this behaviour occasionally for months, but the frequency has become much worse in recent weeks badly impacting WAF, either due to changes since the feature freeze, or perhaps with recent updates of the nVidia drivers.

MythTV Version : 22082M MythTV Branch : trunk Network Protocol : 48 Library API : 0.22.20090919-1 QT Version : 4.5.2 Options compiled in:

linux release using_alsa using_pulse using_backend using_directfb using_dvb using_firewire using_frontend using_hdpvr using_iptv using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_libavc_5_3 using_live using_mheg

I'm using patches 6611 (hdpvr signalmonitor), 6975 (new-audio), 6602 (ringbuffer reset) and 6719 (channel thread).

[databubble]

output from configure

[databubble]

xorg.conf

[markk]

Firstly, as an aside, no "me too's" please. It's a well known issue that's already received a chunk of attention.

Secondly, for the sake of clarity, this is not an issue confined to VDPAU playback. It's a broader issue driven by the interaction between the UI painter and the video renderer, whereby the UI painter is overpainting the colorkey that the video driver uses for the hardware overlay. It affects XVideo, XvMC and VDPAU. I have various hacks and fixes that improve the situation, though none seem to provide a 100% reliable solution.

There is also a related issue with the OpenGL video renderer, though the underlying cause is different.

[markk]

(In [22289]) Disable MythMainWindow? painting when the video window is active. Closes #7206. This seems to primarily fix the VDPAU colorkey/repaint issue - the XVideo problem persists and may actually be due to the size of the mask. m_drawEnabled may now be redundant.

[databubble]

I can confirm that this fixes the problem on my VDPAU front-ends.

THANK-YOU!

You've resolved my (and my wife's) last major annoyance with 0.22.