[mythtv] LiveTV OSD Bug - Investigation

[Paul Wheeler]

I too get this problem occasionally, though dont watch livetv enough
for it to be a major issue. There is already a ticket open with what
appears to me the same problem.

http://svn.mythtv.org/trac/ticket/1452

Paul

On 4/3/06, Johan Venter <johan at vulturest.com> wrote:
> 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 :)
>
>
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>