[ATrpms-users] MythTV bijou and older hardware

[John Pilkington]

Axel Thimm wrote:
> Hi,
> 
> On Sun, Mar 01, 2009 at 11:03:36PM +0000, John Pilkington wrote:
>> With bijou now apparently running happily on my fc10 box - using the 
>> 180.29 driver although not with VDPAU-capable hardware - I thought it 
>> might be worth trying it on my older P4 box under CentOS 5.2.  I found 
>> the packages in the 'bleeding' section and upgraded with Smart, but had 
>> immediate problems.
> 
> As you wrote later on, both 0.22 and 0.21-bijou live in bleeding for
> RHEL5, e.g. you went straight to trunk.

No, the only 0.22 package I see now is the local myththemes one that I 
captured during an earlier abortive upgrade with bleeding enabled. 
Initially I selected the bijou packages by hand.
> 
>> I think that these arose because the bijou libmythtv package requires 
>> libvdpau.so.1 from one of the nvidia-graphics180.xx-libs packages.
> 
> It requires any libvdpau.so.1, it doesn't explicitely need a special
> version.

OK: Smart only found it in the 180.xx packages.
> 
>> It seemed that this stopped my older graphics card being recognized
>> by its appropriate nvidia driver, so that eventually the nv driver
>> was activated and xorg.conf was replaced.
> 
> This doesn't happen that easily. For nv to be used the xorg.conf needs
> to be edited. Have you tried nvidia-graphics-switch?

No: neither the system nor I enjoyed the process.  Yes:  I used 
nvidia-graphics-switch  - but there was some possibility of confusion 
(me/it) because  96.43.07, 09 and 11 were all installed.  Sometimes it 
reported installing a new module, sometimes it looked as if nothing much 
was done.  While the 180.xx-libs packages were installed X wouldn't 
start and eventually nv replaced xorg.conf and took over.  I'm running 
96.43.07 at present because I know that works.

> 
>> When I tried to uninstall nvidia-graphics180.35-libs, Smart would only 
>> offer to install 180.22 instead; but it did allow me to downgrade 
>> libmythtv to the non-bijou version and then uninstall 180.35.  The 
>> resulting installation wouldn't run, saying that it couldn't find the 
>> MythCenter theme.  At this point I reinstalled the original 0.21 fixes 
>> system, only to find that the theme was still missing.  Why?  Because a 
>> local copy of myththemes-0.22-143_trunkxxx had been sneakily installed 
>> because it looked like an upgrade :-(
> 
> True :( The reason is that for RHEL5 the "testing" area is misused to
> mean "may replace RHEL5 parts" and is used by many RHEL5 users. So
> while for F10 the packages could go to "testing" for RHEL5 I had to
> use "bleeding".
> 
> I need to find a better solution to this (like a new
> stable/testing/bleeding split).
> 
>> The system is now working again, and I can still hear the 1 sec fsync 
>> pulse when it's recording.  There are probably several morals in this 
>> tale, but the principal one is (unless I misinterpreted what happened) 
>> not to install the current version unless your graphics card can use the 
>> 180-series drivers.
>>
>> And finally - I did try 180.35 on the fc10 system:  zombie processes, no 
>> ctrl-C, lots of cpu activity, rising over time, to little effect.
> 
> Which processes go zombie, mythtv?

I'm afraid I don't know.  atop just showed 8 zombie processes quite soon 
after a reboot and apparently didn't move on properly to its normal 
10-second cycle.  The system did run unattended for several hours and 
made some recordings, but after that menu transitions in myth took tens 
of seconds and cpu load was very high.