the (un)real thoughts of realbt

After running into problems (and quite frankly, being too lazy to fix them) running my old 3dfx Voodoo3 with TV-out to my TV, I decided to look for a device that would play the movies and TV shows that I had on my computer on my TV without a whole lot of fuss. After some searching, I discovered the Hauppage MediaMVP.

The MediaMVP is a Power PC-powered linux unit that does on-board MPEG 1 and 2 decoding. It connects to your LAN via wired or wireless ethernet, and communicates by various means to pull the data stream and display it on your TV. It comes with a remote control that you can use to browse your media, and play/pause/etc like you would on a VCR. Very useful. It turned out to be a better solution than using the TV-out since this way I don’t have to run over to my PC to make it pause the video.

The unit ships with Windows software for booting the device (the “MVP Server”) and streaming the data from the PC’s hard drive. For DivX, the host PC transcodes on-the-fly to mpeg and then streams to the device. I found the Hauppage software to be kind of ugly and not really all that great.

I decided to give some third-party software a try within a couple minutes of playing with the Hauppage stuff. First, I tried the MediaMVP Media Centre (mvpmc) which doesn’t require a Windows PC at all — better for me, since I don’t have one, apart from my laptop, which is not the way I want to run my MVP. mvpmc is a replacement linux kernel for booting on the MVP (served by tftp from any host) that connects to nfs and cifs (samba, Windows smb protocol) hosts to grab mpeg 1 and 2 data for playing. For DivX, it uses VLC with the telnet interface to stream mpeg to the device. This worked okay, but I ran into some audio sync issues and instability. Some DivX just wouldn’t play.

(The cool thing about mvpmc was that it had busybox on it. I could telnet into my MVP and do all sorts of stuff. Very cool. Not all together useful.)

Finally, I gave in and tried GBPVR, a larger PVR project for Windows. So I built a Windows 2000 virtual machine (since I’m a VMWare junky, it turned out not to be a big deal to run a Windows VM dedicated to the MVP) and set-up GBPVR. I don’t want/need any of the PVR capabilities, but it does a rather nice job of working with the MVP. It works the same way as the Hauppage software in many respects. For DivX, it transcodes and streams. Once I solved some aspect ratio problems (with the help of a utility for GBPVR called ZProcess), things are working relatively smoothly without too many hiccups. I can play my mp3s in the living room now, and listen to low-quality Internet radio stations.

On a side note, I ran into some bizarre issues with my Windows VM access Samba on my main workstation. For some reason, as soon as I started browsing, explorer would lock up for a few seconds. On large files, it would lock-up for a really long time — so long I never waited it out and killed explorer. In the end, I tracked it down to some bizarre problem with an option on my ethernet card: tcp segmentation ofload. Running ethtool -k eth0 tso off seemed to do the trick. There is also an option in Samba that may do the same thing, though I didn’t test it.

Later, I wired up my webcid script to send a YAC ping to the YAC listener plug-in for GBPVR. Now, when someone calls, I get caller ID information popping up on my TV when I’m using the MVP. Very cool, very useless. It was a little too easy to make all the bits interoperate it wasn’t that exciting to see it work.

So far, so good. It’s turned out to be a good $100 investment.

The assert method is a very useful debugging macro for C/C++. It’s great when developing code that other people will be using and extending, to ensure that someone doesn’t do something unintentional. In cases like this, a useful assert(0) will spew an error and abort the instance of the application. It tells the developer “oops: you did something wrong”. Yes, it can be confusing to some developers, and it’s even worse when a user sees it (insert boring rant about the necessity of good breadth testing). But when used well, I quite like it.

At work I’m using the LSB C++ compiler to build our latest product for all Linux Standards Base platforms. I’ve written about how the compiler is buggy before (at least I meant to..), but this time it’s an issue in the assert.h header that ships with the LSB SDK: it’s completely broken.

The macro doesn’t work properly whatsoever.

It’s rather frustrating when something like that is so utterly broken. The only good news is that the LSB folks are taking the bug rather seriously.

Cracks me up.

In other news, my heatsink fell of my cpu/motherboard on my new computer today. That is definitely not a good thing.

After four years of the same old Athlon 1 GHz, I finally have some new hardware. It’s quite fun not to have to wait for anything to load. I’m not going to a big nerd and go on about the specs, however, I do want to write a bit about what works and what does not work with Linux, since it’s quite a different set-up than I’ve had previously.

RAID: my motherboard has on-board “fakeraid” which is poorly supported by the Linux kernel. I wanted RAID 1 (mirroring) and the current kernel (without crazy patches, which I hate doing) doesn’t do any redundancy checking when reading/writing from the RAID array, which basically makes the array useless. So I’m doing software RAID with Linux, which seems to be working well.

SMP kernel: I have a 64 bit dual core cpu. Installed linux-image-k7 worked great — it automatically is running with both cores, no configuring. Didn’t even require a special SMP kernel — it’s all one in. Very convenient.

(Why am I running a 32 bit kernel? Because, quite frankly, 64 bit sounds like a bit of a pain with drivers and the like. It’s just easier to stick with 32 bit for now.)

NVIDIA TwinView: I’m running binary NVidia drivers on my box, with two monitors — my existing ViewSonic widescreen and a regular 4:3 square Dell that I bought from a friend. TwinView is nice becaue I don’t have to worry about annoyances from some of the other lame ways of running dual-head with X. However, one of its major limitations is the inability to run a different DPI on each monitor. So far, I think it’s okay and my fonts aren’t screwy. But I’m kind of paranoid about it since the KDE login screen is quite badly distorted.

Google Earth: I can run Google Earth now, which seems incredibly cool. Except it doesn’t render correctly and I have no idea why.

Multimedia keys: It was surprisingly easy to set-up my multimedia keys on my Microsoft (gasp!) natural keyboard.

That is all for now.

I have spent a lot of time in the last few days arguing with the Linux Standards Base compiler, which is an altered version of GCC that links against LSB-standardised libraries and such. It should act exactly the same as regular GCC, at least in terms of functionality and command-line argument parsing.

The main issue I ran into was exporting symbols on a shared library that are being exported from a static library. What am I talking about? Well, if you speak gcc…

g++ -shared mylib.a mylib2.a -o mysuperlib.so

(Notice I’m using static libraries as filenames, not with the -l library option. It doesn’t make a difference which you use.)

So imagine mylib.a exports some symbols that I want my mysuperlib.so (shared library) to also export. By default, these symbols aren’t needed, so they won’t be exported. This is intended behaviour of the linker since it doesn’t have any knowledge that it should export the symbols, since the linker will only pull out symbols from the static library that it thinks it needs. This is why if you did the same above with object files, it will work as you would probably want. The linker knows you want to link against the entire object file when you link against one — but when you link against a library archive (a static, .a file), it only knows the parts it should “pull into” the linking by what you’re linking against.

The solution to this is to tell the linker to include the whole library (archive).

g++ -shared -Wl,--whole-archive,mylib.a -Wl,--no-whole-archive,mylib2.a -o mysuperlib.so

The -Wl switch passes instructions to the linker. We only want to include the entire library of mylib.a, not mylib2.a — which is why we use –no-whole-archive afterward.

The above code works great. As does the following variation:

g++ -shared -Wl,--whole-archive mylib.a -Wl,--no-whole-archive mylib2.a -o mysuperlib.so

Notice the space instead of the comma after the –whole-archive switch. g++ deals with this fine.

Would you believe lsbc++ (the LSB c++ compiler) does not work with the altered version? It’s true. There seems to be a difference in the way it parses command-line options, even though they are both based on the same code-base. Any guesses as to how long it took me to figure that out?