The case for reviving Firefly

[Anonymous]

Where did my post go?

[mas]

Tested forked-daapd now a bit. Had to manually create it’s /var/cache subdir and then it worked.

Differences noticed vs mt-daapd:
– Twice the memory usage
– 10x higher CPU load (relevant on small systems, less so on more powerful systems)
– scanning of database slightly, but insignificantly slower
– streaming works just the same
– no smart playlists 8-(
– no status/admin interface

Transcoding not tested yet.

But seeing that no coder is in the moment really interested to develop either mt-daapd or forked-mtdappd it seems irrelevant anyway. Both would require for a new coder quite some initial work to put in. For mt-daapd it would be to understand the not so well structured old code. For the fork it would be working on interoperability between distributions and stripping down some libararies/dependencies.

That beeing said the case to revive the project rests for a while longer I guess.

[Anonymous]

MAS
@mas wrote:

Tested forked-daapd now a bit. Had to manually create it’s /var/cache subdir and then it worked.

Differences noticed vs mt-daapd:
– Twice the memory usage
– 10x higher CPU load (relevant on small systems, less so on more powerful systems)
– scanning of database slightly, but insignificantly slower
– streaming works just the same
– no smart playlists 8-(
– no status/admin interface

Transcoding not tested yet.

But seeing that no coder is in the moment really interested to develop either mt-daapd or forked-mtdappd it seems irrelevant anyway. Both would require for a new coder quite some initial work to put in. For mt-daapd it would be to understand the not so well structured old code. For the fork it would be working on interoperability between distributions and stripping down some libararies/dependencies.

That beeing said the case to revive the project rests for a while longer I guess.

It would seem that way. I have had lots of offers to help in the form of testing, and management of the forum. I don’t have a serious offer of any coders willing to move mt-daapd forward. If development is progressing on the other fork is it worth my time and money in getting this project up and running if the focus is on the other.

I am at a fork (pun) now and need to make some harsh decisions.

Do we really want to continue to get this project going, in that I need a team..?

Is it going to be worthwhile?

Are we really going to move this code forward or just maintain it?

Is it better to hang up mt-daapd and move to the new fork?

I need to move forward on this or move my time elsewhere. I have all the resources to manage this project and finance if needed but need some input from the people who use it and want to be involved.

I apologise for my absence but I have a seriously ill daughter due to an RTA

For the record my email address is working and have loads of responses but nothing concrete. My contact details are [email protected]

Andrew

[mas]

Thats what I meant with “rest” – as there is noone who is able to and willing to do some coding, the remaining discussion are all theoretic.

Well, the existing code works, theres just not gonna be any development then. Too bad.

[Anonymous]

I’d be happy for a working forum.

I submitted some code patches over 2 months ago in the nightlies (or perhaps feature request) forum.. I can’t remember which, and those posts have not been approved (this seems to be the only thread that gets new posts)

No I am not willing to say I’m going to do any significant new development.. but it would be nice if there was a forum where folks who wanted to do some things could exchange info.

For me, FF was 98% of what I needed.. my patch, I think, made it 100%.

[Anonymous]

There is some progress.
http://blog.technologeek.org/2010/05/02/315#more-315

[Author]

Posts