| Author |
Message |
|
tjc
|
 Posted: Tue Apr 02, 2013 6:44 am |
|
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
|
This is a weird one, and I haven't found any smoking gun in the logs yet, but hopefully someone else can shed some light.
After a long delayed upgrade from 6.04 to 7.4 the front end seems to go non-responsive when it's been idle for a long while. For example I just got back from a long weekend and found that while the system and the backend seemed fine, the frontend wasn't responding to input. Restarting the frontend did the trick but that's not really a good answer. This has happened 3-4 times now, usually when the FE hasn't been used for more than 24 hours.
|
|
| Top |
|
 |
|
tama103
|
Posted: Tue Apr 02, 2013 9:20 am |
|
|
Joined: Wed Mar 21, 2012 7:59 am
Posts: 63
|
|
Hey tjc.
I have been having a similar issue. I did not have the issue on 7.3, just on 7.4. Does your system respond if you let it sit for long enough? Like 30-60 seconds after an input? Mine does. In order to get things to play nice, I do not need to restart the system, just restart X. I think it might have something to do with RAM and the graphics drivers? I am running a system that is now about 7 years old, and while the RAM looks fine in top and rrdtool, it rarely has more than 10% unused.
|
|
| Top |
|
|
|
RacerX
|
Posted: Tue Apr 02, 2013 10:03 am |
|
|
Joined: Sun Sep 05, 2004 7:06 pm
Posts: 690
|
|
A good tool to test the ram is memtest. If it passes the memory test how about a nvida bug. What kind of hardware?
|
|
| Top |
|
|
|
tjc
|
Posted: Tue Apr 02, 2013 7:02 pm |
|
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
|
This system was very stable with 6.04 for ages, so I wouldn't suspect a hardware issue.
Waiting doesn't make a difference, it's not like the inputs are delayed, they're just completely ignored. Also when I login remotely and kill the FE, X seems perfectly happy afterwards. It's like the FE app has grabbed focus and pre-empted all console input, even events normally handled by the wm or the like.
|
|
| Top |
|
|
|
mattbatt
|
Posted: Tue Apr 02, 2013 9:01 pm |
|
|
Joined: Tue Aug 15, 2006 11:14 am
Posts: 1343
Location:
Orlando FL
|
|
Iv'e had a similar problem. If it sits quietly for too long when I hit a button on the remote it takes about 30 seconds to respond to the remote or the keyboard. I just chalked it up to my old gear but seeing other people with a similar problem makes me wonder...
_________________ My System
|
|
| Top |
|
|
|
tjc
|
Posted: Tue Apr 02, 2013 9:59 pm |
|
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
Based on stuff that appears in the logs, the MythTV FE (or maybe the LinHES FE wrapper script) is doing some funky stuff these days. Code: 2013-04-02T21:33:11.878296-04:00 black3 mythfrontend[1819]: N CoreContext mythmainwindow.cpp:2652 (ExitStandby) Leaving standby mode
2013-04-02T21:33:13.679834-04:00 black3 mythfrontend[1819]: I PreviewGeneratorQueue mythdbcon.cpp:395 (PurgeIdleConnections) New DB connection, total: 3
:
:
2013-04-02T23:03:19.961629-04:00 black3 mythfrontend[1819]: N CoreContext mythmainwindow.cpp:2609 (IdleTimeout) Entering standby mode after 90 minutes of inactivity
There's also lots of chatter in the FE logs about locking and unlocking input devices... Code: 2013-04-01T20:28:07.835485-04:00 black3 mythfrontend[18026]: I CoreContext mythmainwindow.cpp:2538 (LockInputDevices) Locking input devices
2013-04-01T20:28:22.347054-04:00 black3 mythfrontend[18026]: I CoreContext mythmainwindow.cpp:2540 (LockInputDevices) Unlocking input devices
2013-04-01T20:28:23.848339-04:00 black3 mythfrontend[18026]: I CoreContext mythmainwindow.cpp:2538 (LockInputDevices) Locking input devices
2013-04-01T20:29:25.297486-04:00 black3 mythfrontend[18026]: I CoreContext mythmainwindow.cpp:2540 (LockInputDevices) Unlocking input devices
2013-04-01T20:29:28.300073-04:00 black3 mythfrontend[18026]: I CoreContext mythmainwindow.cpp:2538 (LockInputDevices) Locking input devices
2013-04-01T20:30:09.333198-04:00 black3 mythfrontend[18026]: I CoreContext mythmainwindow.cpp:2540 (LockInputDevices) Unlocking input devices
Without the code handy I'm not sure if that is referring to the video input or the keyboard/mouse input.
|
|
| Top |
|
|
|
tama103
|
Posted: Wed Apr 03, 2013 9:45 am |
|
|
Joined: Wed Mar 21, 2012 7:59 am
Posts: 63
|
|
I am afraid that I am of no help when it comes to understanding those logs.
I was planning on adding a work-around by creating a cronjob to restart mythfrontend, or X every night at 3am.
|
|
| Top |
|
|
|
RacerX
|
Posted: Wed Apr 03, 2013 10:04 am |
|
|
Joined: Sun Sep 05, 2004 7:06 pm
Posts: 690
|
|
I have seen this issue but just a thought, rather than accepting the issue maybe someone could test it on R8 on a frontend and see if it occurs.
|
|
| Top |
|
|
|
tjc
|
Posted: Wed Apr 03, 2013 7:51 pm |
|
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
|
I found a config setting that controls the standby thing Under "Services -> MythTV Configuration -> Setup -> General -> 6th screen".
If you set the standby time to 0 it will be disabled. Not sure if that's the silver bullet, but so far so good.
|
|
| Top |
|
|
View unanswered posts
View active topics
Print view
Previous topic Next topic 
LinHES Home
Board index
FAQ
Search
Login 
Register
