Problems with mt-daapd SVN nightlies on Linux

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

[rpedde]

@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

[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?

[rpedde]

@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

[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

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

[rpedde]

@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

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

[Author]

Posts