Present Perfect

Spent the last few days reworking my really hacky RTSP code into fairly nicely objectified RTSP code. I can create media providers given an RTP source class. The source class can be a test stream, a source coming from a file, whatever. The media provider decides how this class will be presented to clients - "live" for a source that's always running and every client gets added to it, "on demand" for when every client has its own streamer and source, and more complex scenarios.

The media provider can then be tied to the RTSP resource tree so that various URL's can cause the provider to, you know, provide.

It's starting to work very well - after rewriting everything so that I could have a Live provider running, doing an On Demand one took me thirty minutes. That tells me my classes are extracted more or less manageably from the heap of code I had.

After that, the fun started. Trying to get various players to actually play stuff from the server. HelixPlayer/RealPlayer is proving to be the biggest pain in the ass. I've had to turn off all of Real's proprietary/extended network stuff to make it focus on doing RTSP/RTP only. Then I had to implement some non-required header fields because otherwise the player either does something silly (like, you know, no Content-base causes it to request relative URI's starting from / and not from the URI it was at), or complains that the server doesn't support the protocol.

Through the power of Open Source however I was able to unpack almost 14 MB of hxplay source code to search for the reason for this last error. Again, it was a header field that the code comments claim is required - though I haven't actually seen that in the spec yet. We'll see I guess.

At the end of the day, RealPlayer on Linux is continuously buffering/congesting on both the live and on-demand mp3 test stream. RealPlayer on Windows plays the latter fine, but not the former. Will take some time to figure out the differences.

Fedora

Got bitten by one of my favourite Red Hat/Fedora rant topics - ext2 disk labels. I absolutely hate them, and Fedora tries to use them as much as possible, often with disastrous results on machines you try to maintain for longer times.

The issue this time was as follows. I had upgraded my dad's home machine last time I was in Belgium from Red Hat 9 to Fedora Core 4. While doing so, we also gave him a new harddisk to do a fresh install, and then put in the old hard disk so that he could clean up and keep files he wanted, and delete the ones he didn't. All of this could be further done remotely.
As usual I edited grub.conf to remove the stupid device labels and put in real partitions.

Now, recently I did a remote upgrade, and after a reboot, the machine didn't come up again. Called my father. It took some time to figure out, but he was claiming it was booting in Red Hat 9 and it was throwing lots of failures. So after some thinking, what happened was this:
- the kernel upgrade rewrote grub.conf
- it used LABEL=/ to define the root partition, as opposed to /dev/sda2 which the other kernel lines specified
- it boots up the RH9 partition from the OLD drive, which also has one partition labeled /
- after some time, it remounts / as read/write. At this point, it mounts the FC4 partition from the NEW drive. Because, you know, it's also labeled /
- the RH9 kernel barfs all over the place as pieces of FC4 try to start up, and nothing works. Not even the network, since, you know, apparently Red Hat did not have the hindsight to put kernel modules for all previous Red Hat kernels in their Fedora installs (for which I can't blame them).

Now, I'm usually pretty careful with the disk labels, making sure I remove them everywhere. But I could have sworn that before, kernel upgrades looked at your grub.conf and tried to copy settings from other lines. Every other line had the partition specified with the device name. Yet *this* kernel upgrade happily ignored that. Causing me to lose a few days trying to debug this problem remotely with my father as the serial console, which as people who have fathers know, is a lot more lossy than a 300 baud modem. It's the kind of serial link that executes random commands you didn't ask for and returns characters out-of-order and skipping a whole lot of them.

Disk labels - I hates them. I absolutely hates them. I have other reasons, but this one tops the list right now. They haven't ever solved a single problem for me.

Unrelated

Robert is a new pornographer.

Spent the last few days reworking my really hacky RTSP code into fairly nicely objectified RTSP code. I can create media providers given an RTP source class. The source class...