The Fugue

My PVR-150 that I got used from eBay would occasionally spaz out and complain “Encoder mailbox not found” when trying to load the firmware. It happened when I first got it, then didn’t happen for months, then happened again and went away with a reboot, then happened and wouldn’t stop until I switched PCI slots.

Then it worked, for about an hour, and puked with “Encoder firmware dead!” or something like that. Something was dead, anyway. I took this as a sign that it wasn’t a driver or IRQ problem, but a bad card. (Yes, I’m rather thick.) So I got a (supposedly) new card from eBay for just a few more dollars than the original used one cost. It has been working for several days without complaint, so I think it must be a bad card.

But if you want to try your luck with this PVR-150, I’ll be happy to mail it to you. Maybe it was a problem with my VIA motherboard.

And most importantly, for those of you out there searching for “encoder mailbox not found”, it may just be time to get a new card. If not, try switching PCI slots.

I had MythTV on falcon, then I got a new graphics card for gwythaint and so I moved the frontend to gwythaint (HD, yay). Then I got a new hard disk and decided to put the big disks in gwythaint, which meant falcon no longer needed to be a mythtv backend of any sort (gwythaint was already doing all the transcoding). Moving the mythtv backend was not as simple as it should have been. These instructions outline what I did at first. The database step was not an issue, and of course copying was simple enough, but MythTV couldn’t find my moved files.

Poking around in the logs revealed it was still trying to get the movies from falcon, even though I had removed the backend on falcon. So as a stopgap I reinstalled the backend on falcon, set it up as a secondary backend, and set up a samba share so it could access the MythTV data storage directory. Now whenever I watched anything it would go back and forth across the LAN. Whee!

I was puzzled by these assertions that you can just move files between storage directories and MythTV would just find them, when it didn’t seem to be even trying on my setup. Then it came to me in a flash of insight. It wasn’t trying to look for them because it thought they were still there. I had the same data storage directory path on both machines: /av/myth. It saw the filenames it expected in gwythaint:/av/myth and so it assumed that no update was needed, although the files were originally on falcon:/av/myth. So I created a symlink from /av/myth to /av/myth-dummy and added that to the storage group. Still, that did not help.

The final solution was to hack the database directly:

mysql> update recorded set hostname='gwythaint' where hostname='falcon';
Query OK, 53 rows affected (0.00 sec)
Rows matched: 53  Changed: 53  Warnings: 0

I bought an MSI NX6200AX-TD256H D2 video card (It’s an NVIDIA GeForce 6200 256MB 8x AGP card) to drive the MythTV frontend, since MythTV can’t manage to play even the most modest content using my trusty old Radeon 7000 (MythTV doesn’t support VIDIX, only XVideo). I hoped that the upgrade would allow me to watch live HD television, which means XvMC.

Before I go any further, the other relevant stats: the computer I’m using (for the purposes of this post, anyway) is an 64-bit AMD Athlon 2800+ running 32-bit Ubuntu 8.04. The motherboard is a VIA K8T800. I’m actually using TwinView to share the Desktop computer with MythTV, but I tested everything with a single-screen (the CRT) to avoid confounding, and using TwinView doesn’t seem to make a difference one way or the other.

All the normal stuff works great, but XvMC does not though it should. Whenever I try to use XvMC, the client (mythfrontend or mplayer, for example) freezes up and must be killed. I tried all the standard tweaks that Google could suggest: enable/disable sync on vblank, enable/disable OpenGL vsync, various xorg.conf settings. I tried just about everything I could think of and then some, and the only thing to make any difference at all is this setting in xorg.conf:

Option "NVAGP" "0"

That is, I disabled AGP. When I do this, XvMC works as it should. After a little research, it perhaps shouldn’t be too surprising that AGP is the problem on a VIA motherboard. At least it’s a lead.

Interestingly, when I downgraded the driver from the latest (173.14.05) to the newer legacy driver (96.43.05), XvMC works fine with AGP enabled. As one would expect, it outperforms the newer driver with AGP disabled. Here’s a performance table:

               (% CPU when playing SD/HD in MythTV)
Driver                       Xv     Xv+linear    XvMC+bob
173.14.05 (AGP disabled)  20/100+    30/100+      12/60+ (OSD is too much)
96.43.05                  20/100+    30/100+       8/45

There’s a few caveats to XvMC, either way I get it to work. When deinterlacing is on, the OSD gets deinterlaced too. This isn’t a pretty sight, though it’s functional. The OSD is always grayscale, in spite of setting XvmcUsesTextures to false in xorg.conf and choosing chromakey. But that doesn’t bother me much, I don’t much like the color schemes of the OSD themes I’ve seen.

I have one more straw to grasp before I consign myself to using the legacy
driver (which I may do if it runs FlightGear and X-Plane ok) or crossing my
fingers for a fixed driver before the Olympics (I intend to submit a bug
report). I’m going to try poking around with AGP driving strength settings in
the BIOS. I tried 0xEA and X wouldn’t start at all, but with the same symptoms
I get with XvMC. That hints at the same cause, so maybe with some kind of
binary search I can stumble on a compatible setting.

So in conclusion, I’m going to try using the legacy driver even though my card is supported by the newer driver, and for OSD reasons only use XvMC for HD.