Opened 15 years ago
Closed 15 years ago
Last modified 15 years ago
#6162 closed defect (fixed)
Remote control events queue then dequeue.
Reported by: | Roo | Owned by: | danielk |
---|---|---|---|
Priority: | minor | Milestone: | 0.22 |
Component: | MythTV - Video Playback | Version: | head |
Severity: | low | Keywords: | remote keypress queue dequeue lirc stall delay |
Cc: | Ticket locked: | no |
Description
Summary
It seems that there is a X11L / X11U pair in the MythMainWindow::customEvent code by way of the GetMythUI()->DoResetScreensaver?() call, this looks like it is blocking the event dispatching. Disclaimer: I am not a Qt expert.
Detail
When watching a recording if I skip forward (or backward) I trigger a problem where further remote events are queued up for some time before being processed.
This is only triggered when sending a remote command after a skip forward. When the stall is introduced I then see keyboard events queued up as well as the network control socket.
After some period of time the events appear to dequeue, I am not sure all events are seen later though. This delay can be a short as a few seconds or as long as a few minutes.
- Reverting [19069] does not help fix the problem
- I do not have xscreensaver or gnome screensaver installed
- Problem still exists if I start frontend without a /dev/lircd
mythfrontend.log
The attached diff shows where the verbose statements were added.
At 2009-01-23 22:28:19.472 you can see that the TV::eventFilter was delayed approx 1:17. This is the typical behaviour seen when the problem was triggered although delay may be longer or shorter.
Much the same thing was seen when debugging was added to MythMainWinow::eventFilter which can be seen here IIRC if pastebin is responding: http://pastebin.ca/1315604
gdb1.txt
First interesting backtrace I have got during the stalled time, thread 1 looks like it is waiting on a lock, that would (I think) explain the delay in the handling of the events. It appears it is stalling the Qt event dispatching, for want of a better term.
Reverting [19567] appears to "fix" the problem. I suspect there is a better fix though. For those that want to try this the svn commandline is:
svn merge -c -19567 mythtv/libs/libmythui/screensaver-x11.cpp
It is also possible that the events at http://cvs.mythtv.org/trac/browser/trunk/mythtv/libs/libmythui/mythmainwindow.cpp#L1608 could be masked if the screensaver disabled.
Attachments (6)
Change History (18)
Changed 15 years ago by
Attachment: | mythtv.diff added |
---|
Changed 15 years ago by
Useful bt from time when event handling is stalled. Thread 1 is of prime interest I think.
comment:1 Changed 15 years ago by
Milestone: | unknown → 0.22 |
---|---|
Owner: | changed from Isaac Richards to danielk |
Status: | new → assigned |
comment:2 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:3 Changed 15 years ago by
screensaver now broken. Does not disable when watching tv. Log says "DPMS Deactivated" but screensaver blanks the screen after usual timeout.
comment:4 Changed 15 years ago by
Priority: | major → minor |
---|---|
Resolution: | fixed |
Severity: | high → low |
Status: | closed → new |
I'll look at this tonight. The code can not print "DPMS Deactivated" without calling DPMSDisable(m_display) in the line before printing that out, so I'm assuming that the problem is with calling the *screensaver-command application which we should be calling every 30 seconds.
comment:5 Changed 15 years ago by
I also experience this issue. Just setting up notifications waiting for a fix. Thanks.
comment:6 Changed 15 years ago by
comment:7 Changed 15 years ago by
I'm attaching the logfile for mythfrontend with -v playback set. The log clearly shows when DPMS is supposed to be disabled, however if I remote call to xset -q on the session, it shows that DPMS is still enabled. It is never getting the signal to disable DPMS down to the OS level. Perhaps, you could add an additional VERBOSE message at the point the DPMS message is actually sent to the system.
Changed 15 years ago by
Attachment: | mythfrontend.2.log added |
---|
comment:8 Changed 15 years ago by
Also, not sure if it is significant, I do have xscreensaver installed, but it is currently disabled. In the past, I've relied on DPMS to take care of the monitor state.
comment:9 Changed 15 years ago by
reran with -v playback. No additional information printed when screensaver activated.
I Added:
XSync(m_display,FALSE);
after DPMSDisable(m_display); in screensaver-x11.cpp (line 144) and this took care of the problem
m_dpmsdeactivated = true; DPMSDisable(m_display); XSync(m_display,FALSE); VERBOSE(VB_GENERAL, LOC + "DPMS Deactivated ");
comment:10 Changed 15 years ago by
Now DPSM doesn't reactivate... have to add XSync in reactivation code as well
Line 155
m_dpmsdeactivated = false; DPMSEnable(m_display); + XSync(m_display,FALSE); VERBOSE(VB_GENERAL, LOC + "DPMS Reactivated.");
Now reactivation works also.
Daniel K. your final solution might be different, but this one works for me for now.
comment:11 follow-up: 12 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
(In [19842]) Fixes #6162. Fixes #6180. XSync after all critial X11 calls in screensaver code.
The DPMS blanking problem went away for Damian when in the debugging patch that called DPMSInfo() after setting the DPMS state.. this was because the query forced X11 to sync. Adding XSync's alone was confirmed to work by jrigg.
comment:12 Changed 15 years ago by
Replying to danielk:
(In [19842]) Fixes #6162. Fixes #6180. XSync after all critial X11 calls in screensaver code.
The DPMS blanking problem went away for Damian when in the debugging patch that called DPMSInfo() after setting the DPMS state.. this was because the query forced X11 to sync. Adding XSync's alone was confirmed to work by jrigg.
I attempted to backport the essential elements of this patch (extra XSync's) to 0.21-fixes (Gentoo package mythtv-0.21_p19961-r1) but it did not solve the problem. This unresponsiveness/remote control lag appeared suddenly, hadn't changed MythTV version in several months. I'll attach the patch I tried to use (applies against 0.21-fixes rev 19961). FWIW, I don't have a DPMS-capable display (TV-out) and don't use a screensaver (don't even think I have one installed).
Debugging patch for attached frontend log