[MythDora] MythDora 5 MythTV RPM upgrade not working

[Chris]

Ryan Pisani wrote:
>> Chris wrote:
>>> Jarod Wilson wrote:
>>>> On Tue, 2008-05-06 at 10:56 -0400, Chris wrote:
>>>>> I just tried upgrading a new MD5 install to the stable 187 level
>>>>> MythTV
>>>>> RPMs and it failed with a missing dependency.
>>>>> Error: Missing Dependency: libmp4ff.so.0 is needed by package
>>>>> mythmusic
>>>> Crap. We built slightly customized mythtv packages to patch in some
>>>> config default changes, and it appears we built against (and shipped)
>>>> the livna faad2 instead of the atrpms one, because it was rpm-newer
>>>> (via
>>>> an epoch bump). The livna package doesn't include libmp4ff though
>>>> (which
>>>> is technically the correct thing to do, because its a private internal
>>>> library interface, and mythtv shouldn't be using it, but native ffmpeg
>>>> aac decode isn't quite there yet, iirc...)
>>>>
>>>> This ought to work:
>>>>
>>>> # rpm -e --nodeps faad2
>>>> # yum --disablerepo=livna --disablerepo=mythdora install faad2
>>>> # yum upgrade \*myth\*
>>>>
>>>> We probably ought to just push an epoch-bumped faad2 with libmp4ff into
>>>> the mythdora-updates repo to smooth this over...
>>>>
>>>>
>>> Way to go!  That worked perfectly!
>>>
>>> I'm doing this in hopes there is a fix for the HD audio noise burst
>>> problem, and to see if my cpu has a little more headroom with these
>>> fixes in place.
>>>
>>> BTW, I wasn't the one who reported the bouncing install screen in the
>>> beta but it made me nauseas too.  The final looks a hell of a lot more
>>> professional.  Thanks!
>>> Chris
>>>
>> Update: It looks like the audio noise problem is fixed but I'm seeing
>> terrible audio sync problems occurring on some channels and it doesn't
>> recover sync.  Also, CPU usage is through the roof, 85-98% just watching
>> 720p broadcasts.  1080i ranges 55-75%.  SLIM playback.
>> Chris
> 
> Chris --
> 
> What's eating the CPU time? Is it mythfrontend or X?
> 
According to top, X is using the biggest percentage of CPU time and that 
percentage runs about 80% for 1080i and 90% for 720p.  Frontend is 
always second to X and runs around 10% for 1080i but jumps to 65-70% for 
720p.

The old 0.20 system shows values about 10% lower for X and the frontend 
  change for the different resolutions is there, but much less dramatic.
Looking at system monitor which displays two cores (P4 H/T) you see a 
60/30 split which bounces back and forth evenly between the cores for 
the old Myth.  The new myth looks more like a 75/90 split. (Both cores 
working harder.)

Since a P4 really only has one cpu and a pseudo-core to manage threads, 
I'm inclined to think the kernel is doing it's job of balancing 
workload, but something is generating more of it.  Whether that's the 
kernel itself, the Nvidia driver, the Mythtv code or something else is 
the $64 question.
Chris