The case for reviving Firefly

[Dave.B]

I would just like to chime in and say thanks for trying to revive this. 1696 was running well for me until recently when my HDD died. Still haven’t got it working again yet, but when I do I’ll be happy to test on uNSLUng, Windows XP and Ubuntu Jaunty/Karmic.

[MrE]

This is the news I’ve been hoping for!

I’ve been checking the forum from time to time, praying there would be an announcement from either Ron or someone else that the project has been revived. Today, it seems, my prayers have been answered 😀

I can’t offer any help with the development, however I’m happy to do testing on my NSLU2 running Lenny as well as my desktop running Arch Linux.

I use Firefly with my Soundbridge Radio and 2x Soundbridge M1001.

Cheers
Emile

[mas]

Indeed good news, that something is going on. It was a bit a shame that Ron had to quit before finishing a final 1.0 version.

As a coder I won’t be much use as this project is way too complex for me and I also don’t have that much time. But I am running the svn version on my gentoo-linux on a VIA Epia system and can test it there. Though I haven’t done it before I may be able to come up with an ebuild for gentoo. There’s one for an outdated version around that one can likely hijack and after updating get into their distri system.

I agree that cleaning up the code should be the major issue for a start. A new forum may also help to organize things though. New features can come once these basics fit again. The main functions are fortunately working quite well even with the svn alpha versions.

[w1ll14m]

Why did Ron have to quit anyway ?

[stretch]

The job he get’s paid to do was interfering with the job he didn’t get paid to do.
The job that pays the bills always wins

[Anonymous]

Heh… I’ve been browsing through these forums fairly regularly for the past year, and this is the first time I’ve actually read this thread. It seems like this convo is getting a bit lost. The subject should be edited to, or a new thread should be started called “Help develop FireFly” or something. But that’s an aside.

I’m a C/C++ developer, who would be very interested in helping with development.
But, here’s the thing… my development environment is Windows. I don’t know the first thing about cross-platform development/compiling, at least in terms of C. And, as a mt-daap user, my sole server right now is running on a NSLU2… so I would have a larger stake in seeing that platform thrive. My fear would be that I would invest a lot of time in the project, and Windows users would be all nice and happy with the features and fixes, but I, myself, wouldn’t actually be able to reap any of the user benefits because the NSLU2 builds would never get updated with those same features and benefits.

I know… pretty selfish. But it has to be a consideration.
There would need to be someone in the project that was knowledgeable in compiling for the NSLU2 before I would get involved.

Also, judging from jblache’s (overly harsh) blog post, it sounds like moving FireFly forward would most likely mean a rewrite, rather than an update. Spaghetti code is way too hard to “update” and maintain. I don’t particularly agree with a lot of jblache’s decisions (iTunes XML playlist support only useful on Mac OS X??? Really? I guess that’s why I’ve been using it with my NSLU2 since the second day I set it up. And the web interface? I’m only in that admin several times a day… can’t imagine why anyone would find it “toss-able”), but it does sound like he’s plowed through the code to a great degree and certainly has an opinion as to how manageable it is to work with 😯

[tmunter]

I’m happy to read, that some people have started working on reviving Firefly. I have been following this thread and am pleased to see, that people with coding experience now are starting to express their interest in the project.
Now that other people with coding experience seem to start joining the project I will also express my interest in joining the effort.

I have started looking through the Firefly source code, but have not at all covered all areas. It was interesting to read jblache’s blogpost and Servomation’s comments. I cannot yet judge whether a complete rewrite is necessary, but when other people take over the source code rewrites will be needed.

It’s great that there has come 76 posts in this thread about reviving Firefly. But maybe it’s now time to take process to the next step: Assemble names of the people who are interested in contributing, make a list over how we get the project running again and which features we want to focus on first. I think we should start a discussion between the people who have expressed interested in the project, so they/we can see, whether they actually want to participate actively.

My biggest issue with Firefly at the moment is the stability. When using Firefly with my Soundbridge, it crashes on a regular basis, nothing a loop in the shell-script starting the program couldn’t fix, but it’s a bit annoying anyways.
In the future I would also like to see UPnP support, so Firefly would be the sole media server program needed.

I’m running Firefly on a embedded (with an Intel Atom cpu) Linux box, so that is where my focus would be. But hopefully some people who can maintain the NAS distributions and the other Linux and Windows distributions will join the project at some point.

[Anonymous]

@Servomation wrote:

Also, judging from jblache’s (overly harsh) blog post

If you’d had to clean up the mess I had to clean up, you would probably understand where that comes from and how justified it is.

@Servomation wrote:

I don’t particularly agree with a lot of jblache’s decisions (iTunes XML playlist support only useful on Mac OS X??? Really? I guess that’s why I’ve been using it with my NSLU2 since the second day I set it up.

I honestly don’t know why you would prefer the iTunes XML playlist over a plain M3U playlist if you’re not already using iTunes. Which would mean you’re on OS X or Windows, two platforms I don’t care much about.

Let me make it clear that I wrote forked-daapd for my own use and amusement with a goal of being fast and lightweight on Linux and Linux only. As a result the code is very tied to Linux features. I’m making this code available because I think I’m not the only one out there looking for a fast and reliable RSP/DAAP server. (and my inbox is there to prove it, btw).

@Servomation wrote:

And the web interface? I’m only in that admin several times a day… can’t imagine why anyone would find it “toss-able”)

The stable portion of the web interface is only useful to trigger a rescan of the library or look at the status of the server. The former isn’t needed anymore, the latter is pretty much useless anyway. And I personally do not care about web interfaces 🙂 Which doesn’t mean there can’t be one, just that it won’t come from me.

@Servomation wrote:

but it does sound like he’s plowed through the code to a great degree and certainly has an opinion as to how manageable it is to work with 😯

You bet I do.

[Anonymous]

@jblache wrote:

I honestly don’t know why you would prefer the iTunes XML playlist over a plain M3U playlist if you’re not already using iTunes. Which would mean you’re on OS X or Windows, two platforms I don’t care much about.

@jblache wrote:

And I personally do not care about web interfaces 🙂 Which doesn’t mean there can’t be one, just that it won’t come from me.

Probably case and point why I will never get involved in this project. “That feature doesn’t fit my needs, so I’m not going to work on it”.
If FireFly is ever to be revived, folks would have to realize that it’s almost akin to a commercial product at this point. It has users who range from technical experts to pure neophites. It’s used on a wide range of server platforms and consumed by a wide range of client agents. The age of designing to one target platform and presuming a genius-level-experienced user is long gone. FireFly needs to be fast and reliable, sure, but it also has to be usable by folks who might not happen to be incredibly technically proficient. And it has to run on platforms that it’s already been committed to by previous versions.

Now… let me make it clear… I certainly don’t expect you, jblache, to develop toward this goal within the context of something you picked up “for your own use and amusement”. Heck, you’re doing it for you, I’d fully expect that you tailor it to your needs. If I knew a lick about compiling for the NSLU2 from my Windows development environment, I might do exactly the same thing.

But, if FireFly were to ever be revived as a “project”, that could not be the case. And my inherent fear would be that a revival would bring together a bunch of developers all determined, as you are, to make mt-daapd exactly what they want, and discounting features that others feel might be useful (like, hey, XML playlist support and web interface*).

* As an aside, I think I mentioned that my FireFly server setup is on a NSLU2. And I consume the streams from clients on Windows (yes, iTunes), my Xbox, and a SoundBridge. I just happen to use iTunes to manage the library (remotely). So, yeah, XML playlist support is pretty mandatory for me. And since the server is on a NSLU2, the web interface is incredibly handy for tweaking settings (such as adding/removing library directories, and creating/editing playlists) when I don’t feel like SSH’ing or telneting into the NSLU2. In addition, because an intensive library scan on a NSLU2 will bring FireFly down (or at least bring it to it’s knees), I’ve turned off automatic scanning and still do my scans manually. So, yeah, again… web interface is incredibly helpful in my particular setup.

[Anonymous]

@Servomation wrote:

Probably case and point why I will never get involved in this project. “That feature doesn’t fit my needs, so I’m not going to work on it”.

Which doesn’t prevent you or anyone else from working on it 🙂

@Servomation wrote:

If FireFly is ever to be revived, folks would have to realize that it’s almost akin to a commercial product at this point.

That’s not how free software works. Want something? Send a patch.

[Author]

Posts