[mythtv] Bizzare repeating key behaviour

Ian Goldberg mythtv at paip.net
Mon Sep 24 14:19:46 UTC 2007

I've done a bunch of debugging of this myself, but now I need to ask for
the collected wisdom of the list. ;-)

I've been running MythTV for years.  I was happily running 0.16 (on a
Debian sid box with two PVR-250s, running both the frontend and backend)
for a long time.  But when I had to move from Zap2It to Schedule
Direct, I needed to upgrade to 0.20.2.  Fine.  I did that, and
everything was working fine (except for a very strage behaviour where,
completely repeatably, around 36:40 into an hour-long recording, the
recorded stream (as verified with mplayer) would go into "fast forward"
for a few minutes, and then settle back down to normal; but that's not
the problem I'm reporting right now).

A chain of Debian sid dependencies (mythweb requires a recent php
requires a recent apache requires a recent libc and all hell breaks
loose) required a massive set of package upgrades on the sid box.
Also, the latest ivtv driver requires a 2.6.22 kernel.  So I upgraded
all of that.

The "fast-forward" problem has gone away (with the new drivers?), and
the backend now seems very stable.  But here's the problem I'm having
with the frontend: keypresses (arrow keys, enter, escape) almost always
"repeat" in the menu screens.  So it's really hard to choose things from
the menus.  This happens whether I'm using lirc with irxevent, native
lirc, pushing the key on my laptop with x2x, or if I push the key on the
actual keyboard.

Even more bizarrely, the debugging I've done so far seems to indicate
that the "native lirc" issue and the "pressing a key" issue seem to be

Native lirc:

If mythfrontend is *not* running, and I run irw, I see this if I push a
key on the remote (and hold it down a brief time):

00000000000017e1 00 CH- hauppaugegrey
00000000000017e1 01 CH- hauppaugegrey

If mythfrontend *is* running (and also irw), I see this:

00000000000017e1 00 CH- hauppaugegrey
00000000000017e1 00 CH- hauppaugegrey

*even if I press CH- for a very short time*.  The lines also take
noticeable time (up to 3 seconds) before they appear.  That is: I push
CH-.  Three seconds later, both of those lines appear at once, and the
selection on screen (in the "Select a recording to watch" screen, for
example) moves two places.  In the "mythfrontend not running" case, the
lines appear instantly.

Pressing a key:

I went as far as instrumenting libqt-mt.so (the version from debian
sid).  In apps other than mythfrontend, it works fine.  But with
mythfrontend, XNextEvent (called from src/kernel/qeventloop_x11.cpp:
QEventLoop::processEvents, line 154) actually returns multiple KeyPress

XNextEvent => 2
Got XKeyPress event, time = 139090174
Sending key event
XNextEvent => 28
XNextEvent => 3
Got XKeyRelease event, time = 139091735
Sending key event
XNextEvent => 2
Got XKeyPress event, time = 139091735
Sending key event
XNextEvent => 3
Got XKeyRelease event, time = 139091736
Sending key event
XNextEvent => 28

(that's from pressing a single key on the real attached keyboard).
Note that there's a KeyPress (2), a KeyRelease(3), another KeyPress and
another KeyRelease.

This is completely replicable.  It happens almost every single time you
press a key.  *But!* not when you're actually watching a program.  While
you're watching TV, both the keypress and the lirc work just fine.  (And
irw reverts to the normal "mythfrontend not running" behaviour.)

Any clue what might be causing this?  Is there some weird state the
mythfrontend menus (but not the playback) are putting the machine in?

Thanks for any help you can give.  As you can see, I'm happy to do any
diagnostics you'd like, up to and including kernel hacking.  ;-)


   - Ian

More information about the mythtv-dev mailing list