Remote control events queue then dequeue.

[Roo]

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.

[Roo]

Debugging patch for attached frontend log

[Roo]

Log showing stalled event processing

[Roo]

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

[danielk]

probable fix

[danielk]

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

[anonymous]

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

[danielk]

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.

[eric.bosch@…]

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

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

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

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

[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 ");

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

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

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

[SiliconFiend@…]

XSync patch for 0.21-fixes