Opened 11 years ago

Closed 11 years ago

Last modified 11 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)

mythtv.diff (6.0 KB) - added by Roo 11 years ago.
Debugging patch for attached frontend log
mythfrontend.log (44.5 KB) - added by Roo 11 years ago.
Log showing stalled event processing
gdb1.txt (27.2 KB) - added by Roo 11 years ago.
Useful bt from time when event handling is stalled. Thread 1 is of prime interest I think.
6162-v1.patch (8.9 KB) - added by danielk 11 years ago.
probable fix
mythfrontend.2.log (24.4 KB) - added by eric.bosch@… 11 years ago.
xsyncfix.diff (1.6 KB) - added by SiliconFiend@… 11 years ago.
XSync patch for 0.21-fixes

Download all attachments as: .zip

Change History (18)

Changed 11 years ago by Roo

Attachment: mythtv.diff added

Debugging patch for attached frontend log

Changed 11 years ago by Roo

Attachment: mythfrontend.log added

Log showing stalled event processing

Changed 11 years ago by Roo

Attachment: gdb1.txt added

Useful bt from time when event handling is stalled. Thread 1 is of prime interest I think.

comment:1 Changed 11 years ago by danielk

Milestone: unknown0.22
Owner: changed from Isaac Richards to danielk
Status: newassigned

Changed 11 years ago by danielk

Attachment: 6162-v1.patch added

probable fix

comment:2 Changed 11 years ago by danielk

Resolution: fixed
Status: assignedclosed

(In [19795]) Fixes #6162. Gives screensaver code it's own connection to the X11 server to avoid conflicts that delay key event processing.

comment:3 Changed 11 years ago by anonymous

screensaver now broken. Does not disable when watching tv. Log says "DPMS Deactivated" but screensaver blanks the screen after usual timeout.

comment:4 Changed 11 years ago by danielk

Priority: majorminor
Resolution: fixed
Severity: highlow
Status: closednew

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 11 years ago by eric.bosch@…

I also experience this issue. Just setting up notifications waiting for a fix. Thanks.

comment:6 Changed 11 years ago by danielk

(In [19829]) Refs #6180. Refs #6162. Adds -v playback debugging to screensaver code.

If you are having problems with the screensaver/dpms please set the timeouts low and run mythfrontend with -v playback and report when the screensaver or dpms standby turns on, and which one is turning on.

comment:7 in reply to:  description Changed 11 years ago by anonymous

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 11 years ago by eric.bosch@…

Attachment: mythfrontend.2.log added

comment:8 Changed 11 years ago by eric.bosch@…

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 11 years ago by jrigg@…

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 11 years ago by jrigg@…

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 Changed 11 years ago by danielk

Resolution: fixed
Status: newclosed

(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 in reply to:  11 Changed 11 years ago by SiliconFiend@…

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).

Changed 11 years ago by SiliconFiend@…

Attachment: xsyncfix.diff added

XSync patch for 0.21-fixes

Note: See TracTickets for help on using tickets.