You are here: Home » Topic » The case for reviving Fireflypage 6

The case for reviving Firefly

This topic contains 135 replies, has 47 voices, and was last updated by  blamm 8 years, 10 months ago.

Viewing 15 posts - 76 through 90 (of 136 total)
  • Author
    Posts
  • #18791

    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 😯

    #18695

    tmunter
    Participant

    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.

    #18681

    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.

    #18685

    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.

    #18686

    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.

    #18687

    nschertz
    Participant

    Looking for a general update on where the project is right now. Andrew aka andrew40.. are you still out there? In your last post you were reorganizing things a bit and looking for a developer team. Has the code been reorganized somewhere for me to take a look at?

    #18688

    Anonymous

    @jblache wrote:

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

    Sorry… but BUZZZZZZZZZ… that’s incorrect. Thanks for playing.

    That’s perhaps how free software used to work… 10 years ago. But that’s what I’m saying. Those days are long since gone. Now that OpenSource is much more accepted as a valid development model, OpenSource projects rise to the level of full products. They have requirements specs, they have architecture drafts, they have source control, they have Q/A and UX phases, they have lifecycles, they address users needs, they have user manuals, they have customer support… just throwing a patch over the wall to hope it sticks doesn’t work anymore. The team assembles a spec to dictate what features will be sought in each successive release. If a user “wants something”, they add it to a wish list and, if appropriate, state how they can help.

    @nschertz… what “reorganization” are you looking for? As far as I know, nothing has been done with the original code, other than jblache’s personal fork. If that’s not still the case, I’m sure Andrew will mention something shortly.

    #18689

    nschertz
    Participant

    Servomation,

    Ok. My mistake. I misread his post. The reorg he was doing was moving the code, reorging the forum and I thought starting down the reorg of the code. It appears like things may be stalled. Andrew had started a twitter blog and provided a few updates, but those stopped. Other than a little recent banter on this forum, things have kind of gone into radio silence on next steps. Maybe just the calm before the storm 🙂 thx

    #18690

    scot
    Participant

    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.

    #18712

    thorstenhirsch
    Participant

    jblache, it would be great if you could help this project, and by that I mean if you could write code for a lot more people than just for you. I think your code is much better, you did a great job. But I can’t use it, too, although my server is based on linux.

    #18680

    Anonymous

    @thorstenhirsch wrote:

    jblache, it would be great if you could help this project, and by that I mean if you could write code for a lot more people than just for you.

    The code is there for anyone who wants to use it or work on it, and I take patches. I have nothing against making things more formal by hosting the project somewhere with a project page and registered contributors, but I want to have contributors first.

    I do not have the time to maintain a cross-platform project all by myself. Moreover, I absolutely do not care about Windows and my care level for Mac OS X is not high enough anymore for me to bother about it (did that back in 2001-2003; it’s been fun but it’s also been very frustrating). I’m not going to pretend I’m interested when I’m not, and I’m not going to pretend patches are good when they’re not, either.

    These are my rules; I want code and not talk, and I want good code. I take the good 2-hour solution over the crappy 5-minute hack.

    As far as platforms are concerned, if you want to port forked-daapd to another platform, go ahead. It shouldn’t be too hard on OS X or *BSD, though it won’t be fun on Windows. Be prepared to become the platform maintainer once you’ve done that, too.

    @thorstenhirsch wrote:

    I think your code is much better, you did a great job. But I can’t use it, too, although my server is based on linux.

    Yeah, requires a 2.6.29 kernel and glibc 2.9 at least, I know, but the kernel features are well worth it.

    ANTLR is a pain too, I know, but again, worth it (though I could and will make a better use of it, time permitting).

    #18691

    Anonymous

    No I haven’t gone.

    I have set a holding page up at https//fireflymediaserver.net/.

    I am awaiting a mass rush of developers who want to start with the code in a new repository and a project manager to manage the repository.

    The forum I am going through and was going to port to a new platform but decided against at this time due to a whole bunch of migration issues with the phpBB forum. So I am awaiting Ron’s reply so that I can add a founder account and migrate (he has previously agreed). Also awaiting a reply from Roku for which the original project was setup for the understand that may not be forthcoming.

    In summary have had hundreds of good wishes but no concrete help yet other than a few who can help with the forum.

    #18692

    Anonymous

    @jblache wrote:

    @thorstenhirsch wrote:

    jblache, it would be great if you could help this project, and by that I mean if you could write code for a lot more people than just for you.

    The code is there for anyone who wants to use it or work on it, and I take patches. I have nothing against making things more formal by hosting the project somewhere with a project page and registered contributors, but I want to have contributors first.

    I do not have the time to maintain a cross-platform project all by myself. Moreover, I absolutely do not care about Windows and my care level for Mac OS X is not high enough anymore for me to bother about it (did that back in 2001-2003; it’s been fun but it’s also been very frustrating). I’m not going to pretend I’m interested when I’m not, and I’m not going to pretend patches are good when they’re not, either.

    These are my rules; I want code and not talk, and I want good code. I take the good 2-hour solution over the crappy 5-minute hack.

    As far as platforms are concerned, if you want to port forked-daapd to another platform, go ahead. It shouldn’t be too hard on OS X or *BSD, though it won’t be fun on Windows. Be prepared to become the platform maintainer once you’ve done that, too.

    @thorstenhirsch wrote:

    I think your code is much better, you did a great job. But I can’t use it, too, although my server is based on linux.

    Yeah, requires a 2.6.29 kernel and glibc 2.9 at least, I know, but the kernel features are well worth it.

    ANTLR is a pain too, I know, but again, worth it (though I could and will make a better use of it, time permitting).

    It sounds that you are wanting to set up your own fork of the source code and get contributors on board. Can I ask is this separate to this project or are you wanting to take part? You have some very strong views but they can be directed in making FireFly a much needed and better project as a whole.

    I would be happy to have you managing the GIT part of the project and contributors but really need to keep this all together, so that the source code is managed properly as you previously said.

    Let me know.

    Andrew

    #18693

    stretch
    Participant

    @andrew40 wrote:

    Also awaiting a reply from Roku for which the original project was setup for the understand that may not be forthcoming.

    Roku has pretty much abandoned the SoundBridge product line.
    From what I’ve seen & read on their forum, the biggest problem with the product was that diagnosing network problems is beyond the skill level of many users & poor quality design of their power supplies, especially the SB Radio.

    #18694

    thorstenhirsch
    Participant

    What about the brand “Firefly”? I guess the rights belong to Roku, so is it possible to call a forked/next version “Firefly 2”?

    edit: …or to keep the current name “Firefly”?

Viewing 15 posts - 76 through 90 (of 136 total)

The forum ‘General Discussion’ is closed to new topics and replies.