Opened 16 years ago

Closed 15 years ago

Last modified 15 years ago

#5660 closed defect (fixed)

Playback intermittently unresponsive to remote control

Reported by: anonymous Owned by: Isaac Richards
Priority: minor Milestone: 0.22
Component: mythtv Version: 0.21-fixes
Severity: medium Keywords: playback unresponsive
Cc: Ticket locked: no

Description

Frequently (about once per recorded show) during playback, I notice that mythfrontend isn't responding to commands from the remote control, which in my case is usually fast forward or exit. If I wait a long time (maybe 15 minutes) the remote commands are all eventually executed, and mythfrontend becomes responsive again.

I've found this workaround, which may provide a clue: if I CTRL-ALT-F1 to switch to a text console, then CTRL-ALT-F7 back to mythfrontend, the remote commands are executed immediately (while I'm still in the text console, judging from the soundtrack) and mythfrontend becomes responsive again.

Attached log excerpt spans the period during which it last happened.

$ mythfrontend --version Please include all output in bug reports. MythTV Version : 16838 MythTV Branch : branches/release-0-21-fixes Library API : 0.21.20080304-1 Network Protocol : 40 Options compiled in:

linux profile 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

Attachments (1)

log.txt (3.1 KB) - added by doumakes@… 16 years ago.
Excerpt of mythfrontend.log

Download all attachments as: .zip

Change History (8)

Changed 16 years ago by doumakes@…

Attachment: log.txt added

Excerpt of mythfrontend.log

comment:1 in reply to:  description Changed 15 years ago by q.steenhuis@…

I have experienced the same problem, with MythTV seeming to ignore or delay keyboard or remote input, and then plays back all at once what appears to be a bunch of queued up clicks. I usually rely on the remote, but when this freezes I try my wireless keyboard, and those presses are also ignored. I haven't tried relying solely on the keyboard to see if using the remote for a while is a necessary predicate to this problem.

So have several people on the user's list, to judge by these threads:

http://www.gossamer-threads.com/lists/mythtv/users/363974?search_string=long%20delays%20responding%20to%20keystrokes%20and%20ir%20events;#363974

http://www.gossamer-threads.com/lists/mythtv/users/364628?search_string=long%20delays%20responding%20to%20keystrokes%20and%20ir%20events;#364628

http://www.gossamer-threads.com/lists/mythtv/users/348526?search_string=delay%20remote%20keyboard;#348526

I can add some more details. I use the HD Homerun box with US cable, and have my frontend connected to the TV using an HDMI cable. I have a Vista MCE remote control (MCEUSB2 driver). I don't have channel icons downloaded. I turned off screensavers and DPMS in xorg.conf. This problem appears when watching live TV and when watching recordings, never when in the menus. It affects both keyboard and remote input. HD Homerun or some other HD content seems to recur in the threads discussing the problem.

My frontend is well-powered. It is a AMD 64 X2, 3.1 GHZ. It has 2 gigabytes of DDR dual channel ram. I am using the 177.82 NVIDIA video drivers, and the on-board 8200 video chipset, but the same problem occurred when using the earlier 177 drivers. I have logged in remotely and run uptime immediately after noticing the freeze. Load was never above about 1.7 (since this is a dual core machine, well below 100% usage). Often this problem occurs when playing back standard def or 480i content, and it happens at least once a day. Usually the first few fast forwards or commercial skips work, but they stop after 10 minutes or so of watching video, sometimes it stops working immediately.

I'm running the newest -fixes build as of 1/13/09, 195 something, on Mythbuntu 8.10 with ubuntu-desktop installed in addition to the default packages. I recently upgraded to this version to see if it fixed the problem, from the stock Mythbuntu 8.10 version. It did not.

I'd be happy to provide more debug information if someone can help me figure out what is needed.

comment:2 Changed 15 years ago by darkroom.dave@…

I have the same problem

Please include all output in bug reports. MythTV Version : 19634M MythTV Branch : trunk Library API : 0.22.20090108-1 Network Protocol : 43 QT Version : 4.3.4 Options compiled in:

linux release using_oss using_alsa using_arts using_backend using_directfb using_dvb using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_lirc using_mheg using_opengl_video using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_live using_mheg

HDHomeRun MCEUSB2 Remote PS2 Keyboard

CPU isn't pegged. irw shows the remote commands are being received. I can ctrl-tab the X server from the keyboard so the keyboard is getting to xorg.

But mythfrontend seems to queue the commands and process them 2-15 minutes later.

Tried turning off/on realtime priority, changing playback groups, Use Events etc.

Nothing solves the problem. When a pause event is finally received the system becomes responsive again so it must be in the playback loop. Seems to happen more often when I am playing HD content.

comment:3 Changed 15 years ago by anonymous

From what I've read this issue is quite prevalent. I've been struggling with it since upgrading a month ago and it is VERY frustrating. I might as well be watching regular old TV since my remote is useless and I'm a captive of the boob tube once again -- no control.

Please, someone, fix this bug or at least propose a work-around. If this were a commercial product I'd already have returned it!

comment:4 Changed 15 years ago by Dibblah

Status: newinfoneeded_new

Does this still occur for anyone? I suspect this was an NVidia driver bug, since this ticket has not seen any action for 5 months.

comment:5 in reply to:  4 Changed 15 years ago by anonymous

Replying to Dibblah:

Does this still occur for anyone? I suspect this was an NVidia driver bug, since this ticket has not seen any action for 5 months.

I was still seeing it with an up to date fixes build last week. I migrated to trunk over the weekend and have not seen it since.

comment:6 Changed 15 years ago by laga

Resolution: fixed
Status: infoneeded_newclosed

Issue apparently fixed in trunk. Closing ticket as 'fixed'. Please re-open if the problem persists in trunk.

comment:7 Changed 15 years ago by stuartm

Milestone: unknown0.22
Note: See TracTickets for help on using tickets.