mythfrontend UI sometimes never paints itself

[danielk]

It appears that it believes itself to be on screen as you can navigate through the menu's and different XML files get loaded. But all you see on screen is the theme background.

I've noticed it for the few days, but it may be an older issue as it appears to be a race condition in the initialization code.

I'm attaching two logs, one where a UI did not get drawn and anthor where it did get drawn.

[Tomi Orava <tomi.orava@…>]

This bug has been around a 1-2 weeks now. Unfortunately, I can't go back in versions because I currently don't have an additional test system to play with.

It seems that the menus will be (usually) displayed after you force a complete refresh by alt-tab key combination or such.

I'm currently running trunk version: 26358.

[stuartm]

Can everyone experiencing this bug please post --version output.

[Tomi Orava <tomi.orava@…>]

Sure:

a) 32-bit, amd athlon/ubuntu lucid/2.6.35.4 kernel

Please attach all output as a file in bug reports. MythTV Version : 26381M MythTV Branch : trunk Network Protocol : 62 Library API : 0.23.20100917-1 QT Version : 4.6.2 Options compiled in:

linux debug using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_directfb using_dvb using_frontend using_hdhomerun using_hdpvr using_iptv using_joystick_menu using_libfftw3 using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_mythtranscode using_opengl using_ffmpeg_threads using_live using_mheg

b) 64-bit amd athlon x2 / ubuntu lucid

MythTV Version : 26341M MythTV Branch : trunk Network Protocol : 62 Library API : 0.23.20100913-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_frontend using_hdhomerun

using_hdpvr using_iptv using_joystick_menu using_libfftw3 using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

c) amd athlon x4 / ubuntu lucid / 2.6.36-rc4 / mythtv server

MythTV Version : 26341M MythTV Branch : trunk Network Protocol : 62 Library API : 0.23.20100913-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_frontend using_hdhomerun using_hdpvr using_iptv using_joystick_menu using_libfftw3 using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

The last two machines are pretty much using the same versions of the trunk, but it does sound like a race condition, just because on the x2 athlon host the alt-tab is usually enough to get the menus displayed, while on the faster x4 host it doesn't work at all. On the faster x4 host, the menus get displayed when you make sure that the running threads get mixed differently/randomly ----> ie. for example by pressing ctrl-z 1-2 of times just before the background gets displayed.

[patrick.zanon@…]

Screen shot of the frontend

[patrick.zanon@…]

I experienced the same problem: after a delay the frontend appears but with very very small writing that cannot be read. The only thing to do is pressing ESC 2 or 3 times until the frontend disappears...

I attached the screenshot (frontend to background.png)

patrick

[stuartm]

Patrick, entirely different issue, that's not even trunk.

[stuartm]

Please test the attached patch, following a hunch by Chris Pinkham I've inverted the behaviour of myth_system so that it doesn't block the UI rendering by default. I can't reproduce the original issue and so I need feedback.

[stuartm]

Possible fix

[Tomi Orava <tomi.orava@…>]

Ok, after a quick test the patch does indeed seem to fix the menu display problem. I'm still very interested in testing the patch with the MythTV server (but have to wait until the morning) as that machine had the worst problems.

I'm also very intested in checking out if this patch actually fixes the root cause that resulted all the DVB devices becoming unavailable:

2010-08-09 19:24:29.672 TVRec(3): ASK_RECORDING 3 29 0 0 2010-08-09 19:24:30.032 TVRec(2): ASK_RECORDING 2 29 0 0 2010-08-09 19:24:30.036 TVRec(4): ASK_RECORDING 4 29 0 0 2010-08-09 19:24:30.050 TVRec(1): ASK_RECORDING 1 29 0 0 2010-08-09 19:25:02.792 TVRec(1): Changing from RecordingOnly? to None 2010-08-09 19:25:04.447 Finished recording Tulosruutu: channel 4350 2010-08-09 19:25:04.529 scheduler: Finished recording: Tulosruutu: channel 4350 2010-08-09 19:25:05.125 Finished recording Tulosruutu: channel 4350 2010-08-09 19:25:06.486 TVRec(1): Changing from None to RecordingOnly? 2010-08-09 19:25:06.598 TVRec(1): HW Tuner: 1->1 2010-08-09 19:25:06.822 DVBSH(/dev/dvb/adapter1/frontend0): Failed to open DVR device /dev/dvb/adapter1/dvr0 : Device or resource busy

The workaround for the above problem was to move the following block to be executed before the fork in myth_system_fork():

/* In case we forked WHILE it was locked */
bool unlocked = verbose_mutex.tryLock();
verbose_mutex.unlock();
if( !unlocked )
     VERBOSE(VB_IMPORTANT, "Cleared parent's verbose lock");

Ie. this lock was always hung and it somehow caused all the DVB-recording problems.

I'll report back in a day about the test results.

[beirdo]

This is not appropriate. This code is to unlock the mutex in the child only. Unlocking before the fork will break more than it ever could possibly fix.

[Tomi Orava <tomi.orava@…>]

Yes, I know very well. I just had to find a quick hack to get rid of constant backend hangs. I do hope these two are somehow related. Anyway, I'm currently running the final test on the server and the last of my three machines now has a working mythfrontend ---> the original menu display problem seems to solved at least here.

Perhaps, I'll see if the second problem gets fixed as well by this very same Stuart's patch.

[beirdo]

That could be related to #8978 as well. Just a thought.

[stuartm]

(In [26442]) Don't disable drawing or disable input devices in the 4 myth_system calls made during frontend startup since they can cause initial draw issues. This is a temp fix since there are very likely more issues caused by later myth_system calls similarly disabling drawing. A proper fix will go into 0.25. Refs #8952

[stuartm]

(In [26443]) Don't disable drawing when calling the ping command on Windows. Refs #8952

[danielk]

(In [26449]) Refs #8952. Adding a repaint() immediately after enabling drawing fixes the repaint issue. The underlaying problem appears to be that MythMainWindow::update(*) calls do not reliably result in a repaint of the window. There are always 2 to 3 update() calls after the SetRepaintEnable?(true) call, but none of them result in drawScreen() being called.

[Tomi Orava <tomi.orava@…>]

A day after the patching everything is back to normal on all of the machines. None of the three has had a single menu display problems.

In case the DVB-devices get locked again as mentioned above, I'll create a new ticket if necessary.

Thanks for the current fix.

[john.p.harvey@…]

I am fairly certain that QT has a bug that is shown if the code follows this sequence widget->Update() widget->setUpdatedEnabled(false) qApp->ProcessEvents?(); widget->setUpdatesEnabled(true)

What happens is that in update the backingstore is marked as dirty & sends an UpdateRequest? event this is processed in ProcessEvents? but discarded because updates are disabled. Any further calls to Update() add to the dirty region but because it is already dirty dont send an UpdateRequest? event.

At startup (in mythtv_setup) we receive 2 events, while blocked looking for the backed ,the updateRequest & the X11 Expose event. neither get processed. By changing setUpdatesEnabled() to d->paintwin()->setUpdatesEnabled() the expose event on mythmainwindow is processed and causes a repaint of it and all its children hence avoiding this problem at that time, but that is not a good solution.

If the system call done from myth_system is quick enough then processEvents wont be called so this is more likely to show up on slower systems.

I have a hunch of a workaround which i will test later today and post a patch for if succesful.

[john.p.harvey@…]

Attached is a patch (paint.patch) which spots UpdateRequest? being called while disables & calls it when we re-enable. This is not significantly different from calling repaint except it only does it if needed & will only update any dirt regions rather than the whole window.

[beirdo]

See also #9016 for more detail on the DVB stuff mentioned above.

[J.Pilk@…]

I just became aware of this ticket and thought it would be worth linking to my recent post on ATrpms-users. It relates to 0.24-fixes under el5 on two (old) boxes, one of which isn't a credible myth device but always _overpaints_ the setup menu screens; the other is ok. The builds for el5 are very new.

​http://www.gossamer-threads.com/lists/atrpms/users/14802#14802

[stuartm]

Ref [3104b1f]