[mythtv-users] Long delays with remote occasionally

[lj]

On Mon, 2008-11-10 at 11:16 -0800, Josh Mastronarde wrote:
> 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
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

I might have stumbled on to a fix, at least for my particular mythtv
box.  I noticed that in my frontend -> Setup -> TVSettings -> Playback
-> Playback Profiles (3/9) was set to CPU++.  I thought that was OK
since I have a Core duo 2.45 GHz with 4 GB of memory fast Sata HD,
etc.   

Maybe not because when I changed the Current Video Playback Profile: to
"High Quality", my initial tests show the "accumulative ir button press
delay" problem is gone away.

Could someone else try this and report the results under this thread?

Thanks
Larry