About a year ago, I bought a SoundBridge, having grown tired of running a media player on one machine or another to listen to music. The SoundBridge really fits my needs perfectly.
The server-side counterpart, mt-daapd (Firefly Media Server), on the other hand… not so much. Feature-wise, it works and does what it’s supposed to do, so the issues aren’t there.
The first issue was with the crappy, below-average packaging of mt-daapd in Debian. I’ve fixed that since I think, at least now it’s in a state where I’m not looking away from the screen while typing apt-get install mt-daapd.
The second issue came after looking at the code, while writing patches for Debian. Eek. It’s horrible in about every aspect you can think of. No coding standard, outdated comments, cruft everywhere, either #ifdef’d out or not, useless code left lying around inside functions, obvious memory leaks, and way more levels of indirection than is actually needed, let alone sane. Also, someone is clearly in deep and urgent need of taking “Pointers in C 101″. My eyes still hurt.
Well anyway, I’ve been contemplating either fixing it or rewriting it because I can’t stand such crappy code. Also, mt-daapd has been unmaintained upstream for something like 2 years, given that the upstream developer just pretty much disappeared.
So, with way more time on my hands than I’d like these days, I’ve finally jumped in, pulled the whole SVN into a git repository and started cleaning things up then rewriting it piece by piece. Good way to keep myself busy, producing something useful while doing so and playing with a couple new things.
This rewrite is called forked-daapd, for lack of a better name at the moment, it’s GPLv2+, and the code is available in a git repository at
git://git.debian.org/~jblache/forked-daapd.git
It’s not a feature-for-feature rewrite. I’ve tossed out a few things.
It’s Linux-only for a start, and then I’ve thrown out the web interface, the XML-RPC interface that goes with it, the iTunes XML playlist support (only useful on Mac OS X) and the smart playlists. Maybe a couple other minor things I can’t think of right now.
It’s Linux-only because it uses signalfd and inotify. It’s built on libevent and pthreads, but doesn’t abuse threads either like mt-daapd does (spawning one thread per HTTP request … seriously). Parsers for the RSP and DAAP queries are built with ANTLR v3. Media handling is mostly done by ffmpeg, though ffmpeg suckiness in parsing metadata in some formats had to be compensated by dedicated metadata parsers. It’s a shame ffmpeg can’t handle raw FLAC streams with VORBIS comments, that is, bog-standard .flac files, while it goes to great length to support proprietary formats (though I should note it fails miserably on WMA too).
So, new things I played with: signalfd, libevent, threads, ANTLR, ffmpeg. Threads aren’t really a first, but I did some new things. inotify isn’t a first either, but it’s the first time I use it to watch events other than IN_CREATE or IN_MODIFY; that leads to quite some unhappiness towards the inotify API, which has some real shortcomings. I’m still shaking my head in disbelief.
It will happily support multiple concurrent clients, even when decoding media files to WAV, without abusing the machine it’s running on. I thought of adding more threading, especially in the decoding case, but I doubt this will be needed by anyone. Unless you’re streaming to hundreds of clients at the same time, which doesn’t look like a plausible usage scenario to me.
I don’t know where I’m going with this project. Right now it works for me and covers my needs. I’ve tested both the RSP and DAAP protocols with my SoundBridge, and DAAP with iTunes. I’m not an iTunes user so I may have skipped on the complicated things with iTunes, although I looked hard.
If there’s enough interest in this project, it can become a full-blown project on Alioth (it can even have a name that doesn’t suck!).