[mythtv-users] Long delays with remote occasionally

[Josh Mastronarde]

On Mon, Sep 8, 2008 at 5:13 AM, Jason Weida <jason.m.weida at gmail.com> wrote:
>
>
> On Sun, Sep 7, 2008 at 7:31 PM, Sean Cier <scier at posthorizon.com> wrote:
>>
>> Another data point.  One of my frontends did this, a lot -- half the
>> time I tried to do something, it'd take two minutes or more to realize
>> I'd hit a button.  Made it completely unusable -- who wants a DVR that
>> won't pause?
>>
>> -- It is *not* lirc: when the problem popped up, both my remote and my
>> (non-lirc) IR keyboard did exactly the same thing.
>>
>> -- Started right after a "latest FC8" -> "latest FC9" upgrade a couple
>> days ago (both on -fixes via atrpms).  *Never* happened before that, and
>> this hardware's been running a frontend for over four years (the latest
>> clean reinstall was at least a few months ago).
>>
>> -- Turning on OpenGL sync seems to have made the problem nearly go
>> away.  I have observed it once since then (in about 1.5 evenings of
>> usage).
>>
>> -- I only ever observed it during playback, not in menus (SDTV; this
>> thing's /just/ powerful enough to play most 720p HDTV streams pulled off
>> cable, but I don't have any at the moment because my backend doesn't get
>> along with my cable box over firewire lately.  Gonna buy an HDHR as soon
>> as Amazon's price goes down again.  I'd already have it if Amazon hadn't
>> canceled their price guarantee policy...)
>>
>> -- I only ever observed it after the playback had been running for at
>> least a minute or two.  Similarly, once it responded to something, it
>> seems like it continued responding for at least a little while.  This
>> could be a sampling bias though.
>>
>> -- At least some of the commands queued up; I'd hit some buttons, then
>> sit and wait for a while, and *usually* eventually they (or at least
>> some of them) would take effect, all in a row.  Of course, I've no idea
>> what level they queued up at.  I *know* keyboard commands queued up, but
>> I'm not 100% certain I observed lirc events queue up.  The keyboard
>> always seemed to provide a higher chance of actually working, eventually.
>>
>> -- Changing playback profiles, video-as-timebase, extra-audio-buffering
>> had no effect.  Enabling realtime threads didn't either, but I didn't
>> verify changing that setting actually worked on the system, so it
>> could've been a no-op anyhow.
>>
>> -spc
>>
>>
>
> Good points, I'm seeing the same.  Playback only, other menus work just
> fine.  Next time it happens to me, I'll check that screensaver/xorg business
> in the other thread, but it sounds a like a different issue since keyboard
> commands are not responding as well (I have a wired PS2 keyboard).  It
> sounds like everyone who has observed the problem is using a lower end
> machine, so maybe that's part of the issue.

Has anyone had any luck in resolving this yet?  I just had a forced
machine upgrade (motherboard failure), and am seeing this issue, and
because so much has changed (new motherboard, video card, fresh OS and
Myth installation) I can't isolate the exact change that caused it.
My symptoms sound similar -- every so often (usually a couple times an
hour at least), there's no response for several minutes to any remote
commands.  The light on the original MCE USB receiver flashes, and
"irw" shows the button presses, so it appears that lirc is receiving
the IR commands properly.  Eventually, Myth responds to some of the
old commands.  This really sounds like a mythfrontend issue to me, but
I don't know how to

Hardware:  Pentium 4 630 (2.8Ghz), Gigabyte GA-EG31M-S2 motherboard,
original MS MCE USB receiver (but using the Philips 1181 IR codes).

OS:  Fedora 9, kernel 2.6.26.6-79.fc9.i686

mythfrontend --version: (latest 0.21-fixes from ATRPMS)
  Please include all output in bug reports.
  MythTV Version   : 18753M
  MythTV Branch    : branches/release-0-21-fixes
  Library API      : 0.21.20080304-1
  Network Protocol : 40
  Options compiled in:
   linux release using_oss using_alsa using_arts using_jack
using_backend using_dbox2 using_dvb using_firewire using_frontend
using_hdhomerun using_iptv using_ivtv using_joystick_menu
using_libfftw3 using_lirc using_opengl_vsync using_opengl_video
using_v4l   using_x11 using_xrandr using_xv using_xvmc using_xvmcw
using_xvmc_vld using_glx_proc_addr_arb using_bindings_perl
using_bindings_python using_opengl using_ffmpeg_threads
using_libavc_5_3 using_live

hwclk --debug reports no errors.

This is a severe WAF hindrance, to say the least :-)

I'm going to try tonight to install from the older RPMs I had on the
previous system's HD partition and see if I can better isolate, but
I'm not confident in that and was hoping someone had figured out the
cause.

Thanks,

Josh