You are here: Home » Topic » Problems with mt-daapd SVN nightlies on Linux

Problems with mt-daapd SVN nightlies on Linux

This topic contains 7 replies, has 1 voice, and was last updated by  floyd 10 years, 8 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #858

    floyd

    I had been running the 0.2.4 release with no problems on my old Red Hat
    system. I decided to try the recent nightly version. I discovered that
    I have to build and install sqlite, which seemed to work ok.

    The server appears to start up and run ok but I was unable to connect
    from iTunes or my Soundbridge. My iTunes in version 6.0.5 (Mac)
    and the soundbriodge is running version 2.5.174. The failure hangs
    both iTunes and the Soundbridge I have to quite iTunes and reboot
    the Soundbridge after attempting to connect. Also, the platylist.html
    browser interface feature (yes I know it is only experimental) fails to
    receive (or display, at least) and song, album or artist information.

    I started to try older nightly versions and as far back as svn-909 I still
    experience these problems. After reading some of the notes for the
    nightly releases I tried rebuilding sqlite (version 3.8.8) with “threadsafe”
    enabled. Now I am able to connect from iTunes but still not from the
    Soundbridge or the playlist.html browser interface.

    I am still using some old version of some libraries but I don’t know
    where to start looking for the culprit. My system is based on RedHat 6.2.
    although I have been updating quite a bit of the software as the need arises.

    I’m also having trouble tracking the various changes that have been
    implemented in mt-daapd since the 0.2.4 version. So it’s hard to tell
    whether the problems are all related to the change to using sqlite or
    something else. Is it possible to have mt-daapd continue to use gdbm
    instead of sqlite?

    I will continue to experiment with it but would appreciate any ideas
    or exteriences others may have had that might provide a clue.

    #7703

    rpedde
    Participant

    @floyd wrote:

    I started to try older nightly versions and as far back as svn-909 I still
    experience these problems. After reading some of the notes for the
    nightly releases I tried rebuilding sqlite (version 3.8.8) with “threadsafe”
    enabled. Now I am able to connect from iTunes but still not from the
    Soundbridge or the playlist.html browser interface.

    I’d probably stick with sqlite2, rather than 3, as there appears to be less volatility in the api. I’ve had much better luck with sqlite2.

    I am still using some old version of some libraries but I don’t know
    where to start looking for the culprit. My system is based on RedHat 6.2.
    although I have been updating quite a bit of the software as the need arises.

    One requirement that I didn’t realize until recently (and haven’t autoconfed for yet) is zlib >= 1.2.0. Most of the machines I’ve run it on have already been 1.2.0, so I didn’t notice it until I tried to compile it recently on an older machine. Kaboom. Segfault on connect from soundbridge.

    Another possibility is that you aren’t loading the rsp plugin. If you kept your old config file, then it probably didn’t get a plugin section added, and consequently doesn’t have any output libraries.

    Try going to the web interface and adding a plugin_dir. Check “/usr/share/mt-daapd/plugins”… make sure you have a bunch of so files in there, and point it there. It might also be in /usr/local/share/mt-daapd/plugins, depending on your –prefix.

    I’m also having trouble tracking the various changes that have been
    implemented in mt-daapd since the 0.2.4 version. So it’s hard to tell
    whether the problems are all related to the change to using sqlite or
    something else. Is it possible to have mt-daapd continue to use gdbm
    instead of sqlite?

    It will. Almost everything that was sql dependant has been factored back out, and I plan to add a gdbm backend again shortly.

    I will continue to experiment with it but would appreciate any ideas
    or exteriences others may have had that might provide a clue.

    My money is on the zlib.

    — Ron

    #7704

    floyd

    Thanks for advice, Ron.

    My system has zlib 1.1.3 installed so I will try updating that first.
    I have the source for zlib 1.2.3. If possible I want to keep the old
    version, in /usr/lib and /usr/include, so that any programs I have
    that require this specific version will still run. If I install the new zlib
    in /usr/local how can I force the mt-daapd build to use the new version?
    Environment variables?

    I was going to try using the older sqlite but I wasn’t able to find the
    source for it that included the configuration files and Makefiles.
    Can the source files from the 2.8.17 zip file just replace the source
    files 3.3.8 src directory?

    #7705

    rpedde
    Participant

    @floyd wrote:

    My system has zlib 1.1.3 installed so I will try updating that first.
    I have the source for zlib 1.2.3. If possible I want to keep the old
    version, in /usr/lib and /usr/include, so that any programs I have
    that require this specific version will still run. If I install the new zlib
    in /usr/local how can I force the mt-daapd build to use the new version?
    Environment variables?

    using –with-id3lib=/usr/local should do it. (I think). Failing that, something like:


    [email protected]:~$ export CFLAGS=-I/usr/local/include
    [email protected]:~$ export LDFLAGS=-L/usr/local/lib
    [email protected]:~$ ./configure ...

    Should probably work.

    I was going to try using the older sqlite but I wasn’t able to find the
    source for it that included the configuration files and Makefiles.
    Can the source files from the 2.8.17 zip file just replace the source
    files 3.3.8 src directory?

    I wouldn’t borrow trouble on that one. I think 3.3.8 should be okay. I’m almost positive that the problem is zlib.

    — Ron

    #7706

    floyd

    I tried building with the newer zlib and still have the same problems.
    However, I noticed this time that one entry on the mt-daapd.log says
    “Error in zlib: -2” so that does seem to point a finger at Zlib.

    I’m not completely sure that mt-daapd is loading the new zlib.
    I tried specifying the path for libid3, as suggested, as well as setting
    the CFLAGS and LDFLAGS environment variable. I also added a log
    trace that prints out the value of ZLIB_VERSION from zlib.h.
    That indicates that at least the new version of zlib.h is being read.
    However, I don’t know how to determine where it linked the library from.
    I assume it’s using the shared objects. Is there a way to have mt-daapd statically link zlib.a?

    I will try some more things later today or tomorrow. Perhaps temporarily
    moving the old zlib files out of the way.

    By the way, and perhaps unrelated: mt-daapd is unable to find or load
    the sqlite3 libraries unless I configure with the option:
    –with-sqlite3-libs=/usr/local/lib

    #7707

    floyd

    I had success by temporarily moving the old version libz files out
    of /usr/lib. And it seems to be working well so far. Hooray!

    However, once I move the old zlib files back into /usr/lib and
    restart mt-daapd, the problems come back.

    The final gcc command in src/Makefile (that links mt-daapd) does
    include -L/usr/local/lib before it has -lz. Perhaps I could get configure
    to specify the actual .so file for zlib as it does for sqlite3 and id3tags.

    #7708

    rpedde
    Participant

    @floyd wrote:

    I had success by temporarily moving the old version libz files out
    of /usr/lib. And it seems to be working well so far. Hooray!

    However, once I move the old zlib files back into /usr/lib and
    restart mt-daapd, the problems come back.

    The final gcc command in src/Makefile (that links mt-daapd) does
    include -L/usr/local/lib before it has -lz. Perhaps I could get configure
    to specify the actual .so file for zlib as it does for sqlite3 and id3tags.

    Hrm… not really… it just adds link and include paths. If you had two different ones, you’d still run in to the same problem.

    You could try setting LD_RUN_PATH to /usr/local/lib before building the binary:

    make clean
    export LD_RUN_PATH=/usr/local/lib
    make

    That should tell the binary to look in /usr/local/lib for libraries before using the regular library search path.

    — Ron

    #7709

    floyd

    Setting an LD_RUN_PATH environment variable didn’t help – not before
    the compile or before starting the server.

    Perhaps using the LD_LIBRARY_PATH variable would work. But for now I
    am going to see what happens if I move the new zlib version into /usr/lib.
    If nothing breaks and things appear stable for a while, I’ll leave it at that
    and hopefully avoid this type of thing in the future.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.