Remote control causes delays and jittery playback

Bug #311772 reported by TJ on 2008-12-27
4
Affects Status Importance Assigned to Milestone
MythTV
Fix Released
Unknown
Mythbuntu
Undecided
Unassigned

Bug Description

There are reports in forums and the mythtv mailing list of 'jerky' playback or delayed reaction and high CPU load when using remote controls via lircd . Some people reported noticing the gnome-screensaver process spiking when a key is pressed.

 http://ubuntuforums.org/showpost.php?p=6385269&postcount=1
 http://www.gossamer-threads.com/lists/mythtv/users/348326?do=post_view_threaded

I've just analysed the call-path for LIRC events and discovered the cause of the delay. It is the result of poking gnome-screensaver for each key-press on the remote.

In summary, the difference between a regular key-press and a remote-control key-press handled by LIRC, is that LIRC creates a custom event. In the Myth front-end the method customEvent() handles the LIRC events. For every event the screensaver's count-down timer is reset. This involves the execution of an external system command each time:

gnome-screensaver-command --poke

The time it takes the system to run that command is what causes the delay. On some systems the delay will not be as noticeable as on others.

It should be possible to use the DBUS API instead to remove this delay. I've developed and am currently testing a patch that uses dbus.

Here's the call-path analysis:

libs/libmyth/lirc.cpp::LircClient::Process(void)
 QApplication::postEvent(mainWindow, new LircKeycodeEvent(code, keycode, true));

 libs/libmythui/mythmainwindow.cpp::MythMainWindow::customEvent(QCustomEvent *ce)
 {
 #if defined(USE_LIRC) || defined(USING_APPLEREMOTE)
    else if (ce->type() == kLircKeycodeEventType && !d->ignore_lirc_keys)
    {
        LircKeycodeEvent *lke = (LircKeycodeEvent *)ce;
        int keycode = lke->getKeycode();

        if (keycode)
        {
            gContext->ResetScreensaver();
            if (gContext->GetScreenIsAsleep())
                return;
 // ...

            QKeyEvent key(lke->isKeyDown() ? QEvent::KeyPress :
                          QEvent::KeyRelease, k, ascii, mod, text);

            QObject *key_target = getTarget(key);
            if (!key_target)
                QApplication::sendEvent(this, &key);
            else
                QApplication::sendEvent(key_target, &key);

 }

 libs/libmythui/mythmainwindow.cpp::MythMainWindow::eventFilter(QObject *, QEvent *e)
 {
      switch (e->type())
    {
        case QEvent::KeyPress:
        {
            QKeyEvent *ke = dynamic_cast<QKeyEvent*>(e);
 }

libs/libmythui/mythmainwindow.cpp::MythMainWindow::customEvent(QCustomEvent *ce)
 libs/libmythui/mythmainwindow.cpp:1515: gContext->DoResetScreensaver();
 libs/libmyth/mythcontext.cpp::MythContext::DoResetScreensaver(void)
  libs/libmyth/mythcontext.cpp::d->screensaver->Reset();
  libs/libmyth/screensaver-x11.cpp::ScreenSaverX11::Reset(void)
   XResetScreenSaver(qt_xdisplay());
   if (d->IsScreenSaverRunning()) resetSlot();
    libs/libmyth/screensaver-x11.cpp::ScreenSaverX11::resetSlot()
     d->ResetScreenSaver();
     libs/libmyth/screensaver-x11.cpp::ScreenSaverX11Private::ResetScreenSaver()
  {
     if (m_xscreensaverRunning)
         myth_system("xscreensaver-command -deactivate >&- 2>&- &");
     else
         myth_system("gnome-screensaver-command --poke >&- 2>&- &");
 }

TJ (tj) on 2008-12-27
Changed in mythbuntu:
assignee: nobody → intuitivenipple
status: New → Confirmed
TJ (tj) wrote :

I've implemented DBus support via the QT3 library. Initial observations seem to show that mythtv isn't affected by the issue so much, but that the gnome-screensaver process still eats a fair amount of CPU time when a series of remote key-presses occur quickly.

This CPU usage can exceed 30% which will indirectly slow down mythtv responses slightly, or cause a sudden rush of response when gnome-screensaver CPU load returns to idle.

As there is no need to poke the screensaver for every key-press I'm going to try an alternative approach whereby mythtv will send a maximum of one poke per minute.

TJ (tj) on 2008-12-28
description: updated
TJ (tj) wrote :

Another observation which might inform on this issue. I just noticed in the log that mythtv is sending *TWO* pokes to gnome-screensaver for each event. I'm not sure why but I suspect it is one for the key-down and one for key-up events:

2008-12-28 16:03:21.492 DBus gnome-screensaver support configured
2008-12-28 16:03:21.499 DBus gnome-screensaver support connected
2008-12-28 16:03:21.499 DBus gnome-screensaver communication test
2008-12-28 16:03:21.500 DBus gnome-screensaver support enabled
2008-12-28 16:03:21.500 XScreenSaver support enabled

...

2008-12-28 16:03:39.011 lircd event: code=Down, keycode=4117
2008-12-28 16:03:39.012 DBus gnome-screensaver poke start
2008-12-28 16:03:39.013 DBus gnome-screensaver poke end
2008-12-28 16:03:39.013 DBus gnome-screensaver poke start
2008-12-28 16:03:39.014 DBus gnome-screensaver poke end
2008-12-28 16:03:41.711 lircd event: code=Down, keycode=4117
2008-12-28 16:03:41.712 DBus gnome-screensaver poke start
2008-12-28 16:03:41.713 DBus gnome-screensaver poke end
2008-12-28 16:03:41.713 DBus gnome-screensaver poke start
2008-12-28 16:03:41.713 DBus gnome-screensaver poke end
2008-12-28 16:03:43.858 lircd event: code=Down, keycode=4117
2008-12-28 16:03:43.859 DBus gnome-screensaver poke start
2008-12-28 16:03:43.859 DBus gnome-screensaver poke end
2008-12-28 16:03:43.860 DBus gnome-screensaver poke start
2008-12-28 16:03:43.861 DBus gnome-screensaver poke end

TJ (tj) wrote :

Looks like I missed the upstream fix in the original searches. Found it now and linked it into this bug report. I'll produce a package using it in my PPA.

Changed in mythtv:
status: Unknown → Fix Released
TJ (tj) on 2009-02-13
Changed in mythbuntu:
assignee: intuitivenipple → nobody
MarcRandolph (mrand) wrote :

Marking as released since upstream fix occured on r19069 and jaunty shipped with fixes19961.

Changed in mythbuntu:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.