<div dir="ltr"><br><br><div class="gmail_quote">On Sun, Sep 7, 2008 at 7:31 PM, Sean Cier <span dir="ltr"><<a href="mailto:scier@posthorizon.com">scier@posthorizon.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Another data point. One of my frontends did this, a lot -- half the<br>
time I tried to do something, it'd take two minutes or more to realize<br>
I'd hit a button. Made it completely unusable -- who wants a DVR that<br>
won't pause?<br>
<br>
-- It is *not* lirc: when the problem popped up, both my remote and my<br>
(non-lirc) IR keyboard did exactly the same thing.<br>
<br>
-- Started right after a "latest FC8" -> "latest FC9" upgrade a couple<br>
days ago (both on -fixes via atrpms). *Never* happened before that, and<br>
this hardware's been running a frontend for over four years (the latest<br>
clean reinstall was at least a few months ago).<br>
<br>
-- Turning on OpenGL sync seems to have made the problem nearly go<br>
away. I have observed it once since then (in about 1.5 evenings of usage).<br>
<br>
-- I only ever observed it during playback, not in menus (SDTV; this<br>
thing's /just/ powerful enough to play most 720p HDTV streams pulled off<br>
cable, but I don't have any at the moment because my backend doesn't get<br>
along with my cable box over firewire lately. Gonna buy an HDHR as soon<br>
as Amazon's price goes down again. I'd already have it if Amazon hadn't<br>
canceled their price guarantee policy...)<br>
<br>
-- I only ever observed it after the playback had been running for at<br>
least a minute or two. Similarly, once it responded to something, it<br>
seems like it continued responding for at least a little while. This<br>
could be a sampling bias though.<br>
<br>
-- At least some of the commands queued up; I'd hit some buttons, then<br>
sit and wait for a while, and *usually* eventually they (or at least<br>
some of them) would take effect, all in a row. Of course, I've no idea<br>
what level they queued up at. I *know* keyboard commands queued up, but<br>
I'm not 100% certain I observed lirc events queue up. The keyboard<br>
always seemed to provide a higher chance of actually working, eventually.<br>
<br>
-- Changing playback profiles, video-as-timebase, extra-audio-buffering<br>
had no effect. Enabling realtime threads didn't either, but I didn't<br>
verify changing that setting actually worked on the system, so it<br>
could've been a no-op anyhow.<br>
<br>
-spc<br>
<div><div></div><div class="Wj3C7c"><br><br>
</div></div></blockquote></div><br>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.<br>
</div>