[mythtv] LiveTV OSD Bug - Investigation
Paul Wheeler
paulrwheeler at gmail.com
Tue Apr 4 08:48:37 UTC 2006
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
>
More information about the mythtv-dev
mailing list