[mythtv] LiveTV OSD Bug - Investigation

[Johan Venter]

Hi all,

I have been experiencing the following issue:
   After certain channel changes in LiveTV (DVB), the frontend ceases to
   respond to input from either a keyboard or LIRC while continuing to
   play the tuned channel - nothing out of the ordinary occurs, nor
   does the OSD display any dialog.

Before I continue, some of you have already dismissed this as a focus 
issue: this is most certainly not a focus issue, and if you will read on 
I will convince you.

At first I believed this may be focus related, and as I wasn't running a 
window manager at the time I installed ratpoison to put that issue at 
rest. When LiveTV stops responding, I continue to switch windows with 
ratpoison using the keyboard just fine, and no amount of switching away 
from and back to myth fixed the issue.

Now for some code. I will describe this in point form as the steps I 
undertook in attemping to debug this issue.

It is long-winded and thorough for the following reasons:
    1. I want to be clear about why I think this is a problem and
    2. I don't understand how to fix it, so someone else with better
       understanding of what should happen will need to provide some
       assistance.

Thanks for your attention.

-----

1. Inserted VERBOSE debugging statements in 
MythMainWindow::TranslateKeyPress (line 622 
libs/libmythui/mythmainwindow.cpp) and LircClient::Process (line 61 
libs/libmyth/lirc.cpp)

RESULT:
   Debugging continues to be printed each time a key is pressed on either
   the remote or the keyboard after LiveTV has ceased to respond
   thus indicating Myth is still receiving my input.

-----

2. Inserted VERBOSE statements inside each if block in 
TV::ProcessKeypress (line 1853 libs/libmythtv/tv_play.cpp).

RESULT:
   After LiveTV has stopped responding the following condition is true.

2057:    if (dialogname != "" && GetOSD() &&
                                     GetOSD()->DialogShowing(dialogname))
2058:    {

-----

3. Some more debugging indicates that the dialog that the OSD still 
thinks is showing is the "channel_timed_out" dialog. Pushing escape 
results in the GetOSD->AbortDialog(dialogname) (~ line 2075, give or 
take some debugging) and the GetOSD->TurnOffDialog (~ line 2079) both 
geting called. The routine then steps into the following loop from which 
it never returns (~ line 2157):

        while (GetOSD()->DialogShowing(dialogname))
        {
          usleep(1000);
        }

-----

3. So, an OSD issue then, apparently the "channel_timed_out" dialog is 
never getting closed. A quick look in libs/libmythtv/osd.cpp shows the 
OSD::TurnDialogOff retrieves the current OSDSet and makes a call to 
OSDSet::Hide:

   void OSDSet::Hide(void)
   {
     m_timeleft = -1;
     m_fadetime = 0;
     m_notimeout = false;
     m_displaying = false;

     if (currentOSDFunctionalType)
     {
         emit OSDClosed(currentOSDFunctionalType);
         currentOSDFunctionalType = 0;
     }
   }

Debugging in here shows that the "if (currentOSDFunctionalType)" is 
never entered as this value is never set to anything other than 0 when a 
"channel_timed_out" dialog is created by OSD::NewDialogBox when it calls 
OSDSet::Display.

-----

4. A grep for OSDFunctionalType gave me this enum in libs/libmythtv/osd.h:

   enum OSDFunctionalType
   {
     kOSDFunctionalType_Default = 0,
     kOSDFunctionalType_PictureAdjust,
     kOSDFunctionalType_RecPictureAdjust,
     kOSDFunctionalType_SmartForward,
     kOSDFunctionalType_TimeStretchAdjust,
     kOSDFunctionalType_AudioSyncAdjust
   };

This seems to indicate that a functionaltype of 0 is not uncommon and is 
in fact the rule, rather than the exception. I fail to understand then 
how OSDSet::Hide and also the duplicated code at line 619 of 
osdtypes.cpp in OSDSet::Draw can succeed in hiding OSD dialogs.

Could someone with more understanding of the code and the OSD please 
help me out with a patch or information on how to fix the 
currentOSDFunctionalType issue such that both OSDSet::Hide and 
OSDSet::Draw are given a chance to succeed --- this not responding thing 
is driving me insane!!

Johan.
PS. No ticket yet in Trac simply because I have no patch - I know how 
the devs feel about tickets without patches :)