You are here: Home » Reply

Reply To: The case for reviving Firefly



I have 1586 working on OpenBSD, minor issues I’ve reported on this forum need to be patched for it to work properly. I don’t think I ever had 1696 working correctly, but that’s been a while.

I would like to see UPnP/DLNA working as well since I now have Phillips Streamium device. Running mt-daapd and mediatomb on the same set of files is just annoying. Running two processor-and-IO-intensive tasks is just annoying.

I’d do it myself but… I’m in the middle of a Ph.D in a completely unrelated field and it’ll be a few years before I can get there. And my C skills are getting rusty as time goes on. The more I push into my brain the more comes out the other side.

I CAN test code and offer build support for OpenBSD and general cross-platform UNIX advice. I can even offer small patches to fix cross-platform issues IF it doesn’t require reading the entire codebase. And, it has to be on my schedule. I understand OpenSource development, been doing it since 1995, but it isn’t my life. I have no interest in pissing matches, debating various methods and all the politics that go with this kind of thing. I just want a good media server that lets me listen to music on my various devices.

Do we need a complete rewrite? I’m not opposed to it (OpenSSH, OpenSMTPd, OpenBGPd… all great tools that were originally seen as completely unnecessary rewrites). But, I’m not going to be the one to do it and I don’t have a dog in that fight. I would like to see a UNIX-based (Linux, Solaris, OpenBSD) server that does RSP/DAAP/UPnP; no need for a web GUI; lightweight database (Sqlite3 seems good); fast; reasonable support for transcoding; the ability to handle 60k+ songs. I like the idea of a plugin driven system (a la Apache?) where the GUIs, protocols, scanners and transcoders can all be plugins. I would like to see Linux-only (inotify) features not REQUIRED (but acceptable). Having the scanners be plugins would allow kevents/inotify/whatever per-platform (as the thread models in Apache2 are handled).

In my experience, someone has to run the show. Every project needs a Linus or Theo. Politics are inevitable, but if “good code always wins” is the attitude, then the political nonsense is minimized. Someone needs to step up and own the project since Ron is out. The rest of the community needs to acknowledge the authority of the new owner and then get to work. Whoever owns the project needs to be clear what the goals are (e.g. Linux only) so that the rest of us can decide if we want to contribute or not. Not that it’d be a loss, but I’m out if this goes Linux ONLY.

In sum: I’d love to see development on mt-daapd revived; there are features I’d like to see added and I’m always a fan of cleaner code. I’ll happily contribute in the small ways I can, but I need to know there is going to be something worth contributing to. For me that simply means that someone steps forward as a leader and shows some kind of progress.