Remote control causes delays and jittery playback
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MythTV |
Fix Released
|
Unknown
|
|||
Mythbuntu |
Fix Released
|
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://
http://
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-screensav
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/
QApplication:
libs/libmythui
{
#if defined(USE_LIRC) || defined(
else if (ce->type() == kLircKeycodeEve
{
int keycode = lke->getKeycode();
if (keycode)
{
if (gContext-
// ...
QObject *key_target = getTarget(key);
if (!key_target)
else
}
libs/libmythui
{
switch (e->type())
{
case QEvent::KeyPress:
{
}
libs/libmythui/
libs/libmythui
libs/libmyth/
libs/
libs/
XResetScreen
if (d->IsScreenSav
libs/
d-
libs/
{
if (m_xscreensaver
else
}
Changed in mythbuntu: | |
assignee: | nobody → intuitivenipple |
status: | New → Confirmed |
description: | updated |
Changed in mythtv: | |
status: | Unknown → Fix Released |
Changed in mythbuntu: | |
assignee: | intuitivenipple → nobody |
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.