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

The case for reviving Firefly

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

Viewing 15 posts - 121 through 135 (of 136 total)
  • Author
    Posts
  • #18757

    Anonymous

    as this all seems to have ground to a halt, i’d like to suggest that we give this one final push.

    i’m not a programmer by any means, but i’d like to be able to help anyway i can. ( hosting, website setup, GIT set-up, forum etc etc)

    i guess the key points are;
    code that will run on windows, linux and maybe osx.
    a structured team where we don’t have to rely on any one person.
    a real push to get the code working again.

    so as a show of hands, who would be interested in doing this?

    #18758

    mas
    Participant

    I would doubt that the fork will run on a NSLU. The guy made the code really for himself and the portability is not (yet?) really high.

    For instance I tried to compile the mt-daapd fork. First I had to install antlr and a few other dependencies. Some work but in the end straightforward to do. And as antlr seems to be a java tool there already it ends for the NSLUs as well I am afraid.

    With my miniPC based on a VIA CPU and gentoo distribution I did not come much further though. After installing all dependencies I get now in the configure run

    checking avl.h usability… no
    checking avl.h presence… no
    checking for avl.h… no
    configure: error: avl.h not found

    Doing a google search does not really reveal the package that belongs to. And a configure run should not bark out just with a missing header file error. There seems to be something either bugged or highly distribution dependant.

    #18759

    mas
    Participant

    And with that beeing said we have a problem. We do not have the manpower in term of coders to do a rewrite on multiple platforms. So we need to focus and throw some things out. After all the old version remains to stay and maybe later we find the manpower to support them as well.

    Thus starting with forked-mt-daapd would be the logical thing. But then we need to get this code at least robust enough that it works on more than one linux distribution and is not a nightmare in dependencies.

    I have no idea if the author of the fork would be willing to help a bit. I for myself am no coder but test it on my platform I can and will. Right now it is just not compilable on a gentoo/VIA system for unknown reasons.

    #18760

    Anonymous

    Face it guys this is going nowhere.

    I’m think of upgrading my NSLU2 with the new Iomega Iconnect. Trouble is it doesn’t support FLAC out of the box.

    #18747

    Anonymous

    where do we go from here?
    Andrew’s attempt at getting this up and running has ground to a halt. partly due to him not being contactable (no fault of his own i’m sure)

    i am more than willing to set another website up, forum, GIT repositaries etc.

    can we have a show of hands to see who would be interested.

    Peter

    #18761

    thorstenhirsch
    Participant

    @Ace/Julien: are you going to release binary packages of forked-daap?

    #18762

    w1ll14m
    Participant

    @mas wrote:

    I would doubt that the fork will run on a NSLU. The guy made the code really for himself and the portability is not (yet?) really high.

    For instance I tried to compile the mt-daapd fork. First I had to install antlr and a few other dependencies. Some work but in the end straightforward to do. And as antlr seems to be a java tool there already it ends for the NSLUs as well I am afraid.

    With my miniPC based on a VIA CPU and gentoo distribution I did not come much further though. After installing all dependencies I get now in the configure run

    checking avl.h usability… no
    checking avl.h presence… no
    checking for avl.h… no
    configure: error: avl.h not found

    Doing a google search does not really reveal the package that belongs to. And a configure run should not bark out just with a missing header file error. There seems to be something either bugged or highly distribution dependant.

    I had this one too, not sure how i fixed it though.
    i got it to run, but it lacked some features.

    I want the scanner to index files it does not support.
    For custom backend goodness 😉
    Had some strange crashes, so i reverted to mt-daapd

    — Edit —
    You need to install avl-0.3.5 (sometimes called libavl)

    Although it uses antlr most of it is for automating compilation and some sort of template based programming (correct me if i’m wrong).
    I think cross compiled binaries could work.

    #18763

    w1ll14m
    Participant

    –configure output–
    checking for evhttp.h… yes
    checking avl.h usability… yes
    checking avl.h presence… yes
    checking for avl.h… yes
    checking for avl_alloc_tree in -lavl… yes
    checking antlr3.h usability… yes
    checking antlr3.h presence… yes



    ldd output:


    Asuka sbin # ldd forked-daapd
    linux-gate.so.1 => (0xffffe000)
    libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0xb7fb4000)
    libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb7f7c000)
    libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0xb7f6f000)
    libdl.so.2 => /lib/libdl.so.2 (0xb7f6b000)
    libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb7f08000)
    libavcodec.so.52 => /usr/lib/libavcodec.so.52 (0xb75b7000)
    libavformat.so.52 => /usr/lib/libavformat.so.52 (0xb74fb000)
    libswscale.so.0 => /usr/lib/libswscale.so.0 (0xb74ba000)
    libavutil.so.50 => /usr/lib/libavutil.so.50 (0xb74a7000)
    libconfuse.so.0 => /usr/lib/libconfuse.so.0 (0xb749b000)
    libevent_core-1.4.so.2 => /usr/lib/libevent_core-1.4.so.2 (0xb7491000)
    libnsl.so.1 => /lib/libnsl.so.1 (0xb7479000)
    librt.so.1 => /lib/librt.so.1 (0xb7470000)
    libresolv.so.2 => /lib/libresolv.so.2 (0xb745c000)
    libavl.so.1 => /usr/lib/libavl.so.1 (0xb7459000)
    libmxml.so.1 => /usr/lib/libmxml.so.1 (0xb744e000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xb7437000)
    libantlr3c.so => /usr/lib/libantlr3c.so (0xb7424000)
    libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb73a6000)
    libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb73a1000)
    libc.so.6 => /lib/libc.so.6 (0xb7264000)
    /lib/ld-linux.so.2 (0xb7fd3000)
    libz.so.1 => /lib/libz.so.1 (0xb7251000)
    libm.so.6 => /lib/libm.so.6 (0xb722a000)
    libdirac_encoder.so.0 => /usr/lib/libdirac_encoder.so.0 (0xb7195000)
    libdirac_decoder.so.0 => /usr/lib/libdirac_decoder.so.0 (0xb7126000)
    libfaac.so.0 => /usr/lib/libfaac.so.0 (0xb7114000)
    libfaad.so.2 => /usr/lib/libfaad.so.2 (0xb70d6000)
    libmp3lame.so.0 => /usr/lib/libmp3lame.so.0 (0xb705e000)
    libopenjpeg.so.2 => /usr/lib/libopenjpeg.so.2 (0xb7041000)
    libspeex.so.1 => /usr/lib/libspeex.so.1 (0xb702a000)
    libtheora.so.0 => /usr/lib/libtheora.so.0 (0xb6ff9000)
    libogg.so.0 => /usr/lib/libogg.so.0 (0xb6ff3000)
    libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0xb6ef7000)
    libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb6ec4000)
    libx264.so.78 => /usr/lib/libx264.so.78 (0xb6e29000)
    libxvidcore.so.4 => /usr/lib/libxvidcore.so.4 (0xb6d14000)
    libbz2.so.1 => /lib/libbz2.so.1 (0xb6d03000)
    libstdc++.so.6 => /usr/lib/gcc/i486-pc-linux-gnu/4.4.2/libstdc++.so.6 (0xb6c10000)
    libgcc_s.so.1 => /usr/lib/gcc/i486-pc-linux-gnu/4.4.2/libgcc_s.so.1 (0xb6bf1000)



    Not sure what is needed on a nslu like device?
    If intrested, i can upload these binaries somewhere..

    hehehe i have those 🙂

    Running gentoo and as stated above you need to install avl/libavl (search for the correct version as said above) or else you get something totaly different.
    If you can’t find it i can upload the source somewhere.

    #18764

    Anonymous

    Do all the features work in your case william?

    After compiling does one still need java?

    Is glibc 2.9 mandatory?

    #18765

    mas
    Participant

    Ok, after about 2h of fixing the dependency issues I got it and what an amazingly long lib list:

    -rwxr-xr-x 1 root root 1175053 16. Mar 16:05 forked-daapd
    sprinter sbin # ldd -r forked-daapd
    linux-gate.so.1 => (0xb7783000)
    libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0xb7767000)
    libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb772d000)
    libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0xb7720000)
    libdl.so.2 => /lib/libdl.so.2 (0xb771c000)
    libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb7653000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xb7639000)
    libavcodec.so.52 => /usr/lib/libavcodec.so.52 (0xb6d7c000)
    libavformat.so.52 => /usr/lib/libavformat.so.52 (0xb6cd0000)
    libswscale.so.0 => /usr/lib/libswscale.so.0 (0xb6ca2000)
    libavutil.so.50 => /usr/lib/libavutil.so.50 (0xb6c8f000)
    libconfuse.so.0 => /usr/lib/libconfuse.so.0 (0xb6c83000)
    libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0xb6c49000)
    libogg.so.0 => /usr/lib/libogg.so.0 (0xb6c42000)
    libm.so.6 => /lib/libm.so.6 (0xb6c1c000)
    libtag_c.so.0 => /usr/lib/libtag_c.so.0 (0xb6c17000)
    libtag.so.1 => /usr/lib/libtag.so.1 (0xb6b7f000)
    libevent_core-1.4.so.2 => /usr/lib/libevent_core-1.4.so.2 (0xb6b75000)
    libnsl.so.1 => /lib/libnsl.so.1 (0xb6b5d000)
    librt.so.1 => /lib/librt.so.1 (0xb6b54000)
    libresolv.so.2 => /lib/libresolv.so.2 (0xb6b3f000)
    libavl.so.1 => /usr/local/lib/libavl.so.1 (0xb6b3c000)
    libantlr3c.so => /usr/lib/libantlr3c.so (0xb6b26000)
    libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb6ab0000)
    libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb6aaa000)
    libc.so.6 => /lib/libc.so.6 (0xb6960000)
    /lib/ld-linux.so.2 (0xb7784000)
    libz.so.1 => /lib/libz.so.1 (0xb694c000)
    libmp3lame.so.0 => /usr/lib/libmp3lame.so.0 (0xb68d7000)
    libopenjpeg.so.2 => /usr/lib/libopenjpeg.so.2 (0xb68b9000)
    libspeex.so.1 => /usr/lib/libspeex.so.1 (0xb68a1000)
    libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0xb67a7000)
    libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb677d000)
    libx264.so.78 => /usr/lib/libx264.so.78 (0xb6707000)
    libxvidcore.so.4 => /usr/lib/libxvidcore.so.4 (0xb661c000)
    libbz2.so.1 => /lib/libbz2.so.1 (0xb6609000)
    libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/libstdc++.so.6 (0xb651d000)
    libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/libgcc_s.so.1 (0xb650f000)



    Was quite a nightmare to get this to compile on gentoo-linux. Except installing the antlr3 packages it was required to

    1. Manually download the avl-0.3.5 source, compile it and install it manually as the makefile of this old package seems to be not compatible with a modern Make version really. Sorry, such old, outdated stuff should not be used any more. Theres likely a reason that no gentoo ebuilt exists for this. I bet it will give trouble in other distributions as well.

    2. Manually downloading and installing the runtime/C stuff and headers as the existing antl3 package from gentoo didn’t seem to include the headers from the C runtime. Also nasty but I am blaming gentoo here. Seems theit antlr3 isn’t a real developer package.

    I haven’t yet found time to really test the forked-mtdaapd executable, but in order to use it as a substitute or starting point for new development I think that it would be necessary to rework the code from forked-daapd to not use antlr and avl as I foresee otherwise problems also with other distributions.
    And we would likely want something that at least runs on the Top10 linux distributions without too many troubles of portability.
    It would also not be a bad thing to remove eventually some of the dependencies, as the list is mighty long.

    Just compare to the old mt-daapd version, which is also half the size of the binary:

    sprinter sbin # ldd -r /usr/sbin/mt-daapd
    linux-gate.so.1 => (0xb7868000)
    libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0xb7850000)
    libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0xb783f000)
    libdl.so.2 => /lib/libdl.so.2 (0xb783b000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xb7822000)
    libid3tag.so.0 => /usr/lib/libid3tag.so.0 (0xb7810000)
    libz.so.1 => /lib/libz.so.1 (0xb77fc000)
    libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb7732000)
    libogg.so.0 => /usr/lib/libogg.so.0 (0xb772b000)
    libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb7701000)
    libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0xb76f8000)
    libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0xb76bf000)
    libc.so.6 => /lib/libc.so.6 (0xb7575000)
    libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb753a000)
    /lib/ld-linux.so.2 (0xb7869000)
    libm.so.6 => /lib/libm.so.6 (0xb7514000)

    So in short, why is this fork – after stripping some functions out – using soo many libraries?

    #18766

    Anonymous

    Where did my post go?

    #18767

    mas
    Participant

    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.

    #18768

    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

    #18769

    mas
    Participant

    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.

    #18770

    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%.

Viewing 15 posts - 121 through 135 (of 136 total)

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