Opened 9 years ago

Closed 8 years ago

#8952 closed Patch - Bug Fix (Fixed)

mythfrontend UI sometimes never paints itself

Reported by: danielk Owned by: stuartm
Priority: critical Milestone: 0.25
Component: MythTV - User Interface Library Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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.

Attachments (5)

no-ui.txt (5.8 KB) - added by danielk 9 years ago.
ui.txt (5.7 KB) - added by danielk 9 years ago.
frontend to background.png (10.7 KB) - added by patrick.zanon@… 9 years ago.
Screen shot of the frontend
mythsystem_flags.diff (12.1 KB) - added by stuartm 9 years ago.
Possible fix
paint.patch (1.3 KB) - added by john.p.harvey@… 9 years ago.

Download all attachments as: .zip

Change History (27)

Changed 9 years ago by danielk

Attachment: no-ui.txt added

Changed 9 years ago by danielk

Attachment: ui.txt added

comment:1 Changed 9 years ago by Kenni Lund [kenni a kelu dot dk]

Status: newassigned

comment:2 Changed 9 years ago by 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.

comment:3 Changed 9 years ago by stuartm

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

comment:4 Changed 9 years ago by 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.

Changed 9 years ago by patrick.zanon@…

Attachment: frontend to background.png added

Screen shot of the frontend

comment:5 Changed 9 years ago by 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

comment:6 Changed 9 years ago by stuartm

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

comment:7 Changed 9 years ago by 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.

Changed 9 years ago by stuartm

Attachment: mythsystem_flags.diff added

Possible fix

comment:8 Changed 9 years ago by 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.

comment:9 Changed 9 years ago by 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.

comment:10 Changed 9 years ago by 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.

comment:11 Changed 9 years ago by beirdo

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

comment:12 Changed 9 years ago by 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

comment:13 Changed 9 years ago by stuartm

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

comment:14 Changed 9 years ago by stuartm

Milestone: 0.240.25
Priority: majorblocker

comment:15 Changed 9 years ago by 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.

comment:16 Changed 9 years ago by 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.

comment:17 Changed 9 years ago by 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.

Changed 9 years ago by john.p.harvey@…

Attachment: paint.patch added

comment:18 Changed 9 years ago by 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.

comment:19 Changed 9 years ago by beirdo

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

comment:20 Changed 8 years ago by stuartm

Priority: blockercritical
Status: assignedaccepted
Type: defectPatch - Bug Fix

comment:21 Changed 8 years ago by 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

comment:22 Changed 8 years ago by stuartm

Resolution: Fixed
Status: acceptedclosed

Ref [3104b1f]

Note: See TracTickets for help on using tickets.