[mythtv-users] mythtranscode and mythcommflag extreme CPU usage

[hwertz at voltron.homelinux.org]

     I thought I'd post up a problem and solution I've found.. it's IMHO 
quite weird.
     In short, I've had the problem that seems to be mentioned periodically 
on mythtv-users and mythtv-dev where mythcommflag will hog CPU for a while, 
and mythtranscode will REALLY hog it.  I tried using CFQ to adjust disk I/O 
priorities without effect, plus using the deadline I/O scheduler and the 
anticipatory scheduler; CPU nice values didn't seem effective either.  Of 
course I checked hdparm and the job queue settings and they were cool too.

      Softwarewise, I'm running Gentoo with everything up to date; that 
includes mythtv-0.19_p10505 (9163 had the same problem though at least with 
mythcommflag).  I have a MSI Mega180 (nforce2 board..) with Athlon XP 2200+, 
replaced RT2400 (802.11b) miniPCI card with RT2500 (802.11G), and a bt878 
card (Hauppage WinTV).  I've been running MPEG4 recording with all 4 quality 
options on (HQ, 4MV, and both interlace options).  Also, the MP3 is set to 
quality 2 instead of 7 -- 7 sounds tinny and crappy to me.  I set mythbackend 
to realtime priority to ensure I don't get screwy recordings.  After 
mythcommflag started to act up for me (it didn't with 0.17), I threw on a 
patch I found on this list or maybe myth-dev to pause commflag and transcode 
jobs when recording or playback was happening (IMHO, this may still be a 
good patch for very slow systems).  More recently, I switched to 
rtjpeg recording so there'd be more CPU cycles for me to use while recording 
and playback were happening.. but mythtranscode really kills the system, even 
when not recording.  It took about 5 minutes just to bring forward an already 
running top, type k and the pid of the offending mythtranscode, it was so 
slow.  Load average was above 40. mouse got jerky too.. When I recovered the 
RT2500 had lost it's connection too.

      My findings:
      Yes, my job queue is set to low CPU usage 8-).
      mythcommflag causes it's slowdown during the logo search only.  The 
commercial flagging's framerate is governed (with the jobqueue low CPU usage 
option) but the logo search isn't.
      mythtranscode isn't governed either.
      I found a solution!  I rebooted with pci=noacpi kernel option, and 
everything was all beer and cigarettes... the logo search and 
mythtranscode just soak up all the idle time, and the non-logo search part 
of mythcommflag uses roughly 5% CPU like it used too.  Very weird too 
because I've been running without this flag since I got the box... I 
haven't had a hint of I/O problems even when running hdparm, find, 
updatedb etc. .. The only thing that seems to trigger this is the new 
mythcommflag logo search and more recently with mythtranscode. The jerky 
mouse etc. I guess were due to high amounts of lost interrupts? Anyway, 
there 'ya go.. this problem some people have been having isn't even 
really a bug in mythtv, it's some hard-to-hit kernel or hardware bug 8-).