mythfrontend stops responding to input after channel change

[ihateyou0@…]

Having upgraded from 0.18 to 0.19, the first time you change channel in live tv, either by typing a channel number or from the osd/schedule, mythtv tunes to the channel successfully but then stops responding to all keyboard input, including the escape key. This occurs 100% of the time. Restarting the frontend makes it work again, until you change the channel again.

The second part of this ticket may or may not be related:

​http://svn.mythtv.org/trac/ticket/1227

The following forum thread (along with one or two others) is definitely related:

​http://www.gossamer-threads.com/lists/mythtv/users/186516?search_string=please%20please%20help;#186516

It might be important to note that we are also using a dibcom 3000 dvb-t usb1.1 device as is the poster. In our case, the Artec T1.

Lots of people suggested on the forums that this is a focus issue caused by window manager problems (we are using gnome). We tried alt-tabbing and using the mouse to regain focus and it made no difference. We upgraded to the latest version of the 0.19-fixes branch in svn (on 03/03/06 yesterday) and this also made no difference.

We managed to work out that input for live tv is handled in libs/libmythtv/tv_play.cpp

Defining DEBUG_ACTIONS 1 allows you to see that keypresses are still being recieved on line 1734 even though the frontend is not responding, proving this is not a focus issue.

Some debugging and adding of printfs showed that the problem seems to lie with the if statement on line 1902. Before a channel change, this block is not entered when a button is pressed and keyboard input works. However, after a channel change all keypresses seem to fall into this if statement. Replacing line 1902 with "if (false) {" causes keyboard input to start working again. Commenting out lines 1562, 1563, 1566 and 1567 is also required to make the escape key cause live tv to exit back to the main menu after a channel change.

Obviously I didn't submit this as a patch because it probably isn't the right way to fix this. Hopefully that's enough for someone to figure out why that if statement is being entered when it shouldn't be.

Adam Davison

PS As per the howto i tried to assign this to someone, i put ijr as osd was the closest category I could find for this. Hope that isn't a problem.

[johan@…]

Here are my findings on this issue (which I experience quite regularly after random channel changes with DVB-T) which were posted to the mailing list.

---

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.

[Isaac Richards]

Stop playing with trac.

[Isaac Richards]

Try to reproduce with current SVN.

[stutty@…]

I'm still seeing these symptoms (in 10116), not on every channel change, approx. 1 in 10 fails. Upgraded from fixes to latest svn branch [Version: 10116] specifically to fix this.

Will add logs if required, still compiling my other frontend [EPIA] (which has the debug).

[dscoular@…]

GDB backend trace

[dscoular@…]

GDB backend trace

[dscoular@…]

Hi All,

I just wanted to say that I have been experiencing this for a while with 0.19-fixes. mythfrontend livetv channel changing causes the frontend to stop responding to input. Interestingly, the telnet interface also seems to stop working. This happens with my aging Hauppauge Nova-T DVB card (tda1004x frontend).

It happens in about one change in ten as described above.

I've attached backtraces for the frontend and backend (but I don't hold out much hope for them being useful). Also, I incorrectly described both attachments as being backend traces. The filenames correctly indicate which is which.

Just wanted add my 2 cents to support this ticket.

Cheers,

Doug

[stutty@…]

Have to say this has not been a problem for the last few builds I've done, currently running version 10340 of the main trunk without seeing this issue. Nasty race condition or now fixed? (In fact the main trunk has proved much more stable than the fixes branch for me).

[mikhaildvane@…]

I too had this problem with my pcHDTV3000. Occasionally when the problem would occur, I would notice the "channel_timed_out" dialog flash very briefly on the screen. This seems to be consistent with what others have found in their debug. I remembered that the tuning timeout and tuning lock timers for ATSC cards are set much shorter than some other DVB cards, so I went and made them longer in mythtv-setup (3000 ms and 5000 ms, respectively).

With these longer timeouts, I no longer see the issue.

I'm not sure if it's a true fix, or just a way to avoid the issue, but it's an easy thing to try. I'm running 0.19-fixes svn revision 10190.

Mik

[henke@…]

I have tried the suggestion to workaround for a few days. The problem does not occur as often as it used to (I believe), but I still experience it from time to time. Only for live TV, never when I watch recordings.

I am more than willing to contribute with any logs that may help pinpointing the problem. Just let me know.

Henrik

[danielk]

Closing this 0.19 ticket, the way this works in svn head is a little different. There is still a short period where we do not respond to commands other than ESC, but we no longer have the problem of short recordings messing up the ring buffer switching unless you start LiveTV just before a program change on the channel.