OpenBSD woes and a few fixes

[scot]

OpenBSD -current (I track it weekly) on an AMD64 multi-processor system.

All other components (howl, sqlite) are standard OpenBSD packages–no custom builds.

I’ve been running 1586 for months with a few modifications (see below) and things work fine. On every nightly I’ve tried since then (about 5, including 1677 and 1696) when I experience a very predictable crash.

The db scans correctly, daemon starts up, first track plays. When the track changes, either because the song ended and automatically went on to the next or when a new song was selected mid-stream, mt-daapd crashes. I’ve noticed you are working on the socket code, I’m guessing the problem is in there.

To build Firefly I use the following settings:

./configure –enable-howl –enable-sqlite –with-howl-includes=/usr/local/include/howl –with-howl-libs=/usr/local –with-id3tag=/usr/local –prefix=/usr/local/mt-daapd

in mt-daapd-svn-1696/src/mp3-scanner.c (version 1670) line 369 I change “if(err == -1) {” to “if(err != 0) {” so the scan can make it past the first directory. We’ve discussed this elsewhere on this forum.

in mt-daapd-svn-1696/compat.h I have to manually “#define HAVE_STRCASESTR 1” since configure guesses wrongly.

“make install” puts the plugins into /usr/local/mt-daapd/lib/mt-daapd/plugins/…. with their version numbers *.so.0.0 but the binary looks for them in /usr/local/mt-daapd/share/mt-daapd/plugins without the version numbers so I have to manually move them.

With these changes, 1586 works like a champ. Anything after that looks good but crashes when a second song is accessed.

[rpedde]

@scot wrote:

The db scans correctly, daemon starts up, first track plays. When the track changes, either because the song ended and automatically went on to the next or when a new song was selected mid-stream, mt-daapd crashes. I’ve noticed you are working on the socket code, I’m guessing the problem is in there.

I’m not handling SIGPIPE when the socket closes. I’ve noted that myself, but keep forgetting to add that in (as the platform I’m on doesn’t care. 🙂

I’ll try and remember to add that. If it isn’t fixed next nightly, can you ping me about it again?

in mt-daapd-svn-1696/compat.h I have to manually “#define HAVE_STRCASESTR 1” since configure guesses wrongly.

I may just start using all the compat functions regardless of whether the platform natively supports it. Makes it easier to see errors in the compat code. Plus, I’m either too stupid to use autoconf, or autoconf is too stupid to use. I don’t dare guess which of those two is the case. So I’ll just sidestep the issue.

“make install” puts the plugins into /usr/local/mt-daapd/lib/mt-daapd/plugins/…. with their version numbers *.so.0.0 but the binary looks for them in /usr/local/mt-daapd/share/mt-daapd/plugins without the version numbers so I have to manually move them.

Some time ago, the default paths changed, as platform specific libs should really go in pkglibdir, not pkgdir. But unless you updated the config file, it won’t find them there.

As far as the .0.0 goes, that’s a libtool issue, unless I’m dorking that up too.

In any case, aside from the .0.0 issue, I think the rest are fairly simple issues. I’m gonna throw this whole thread in a bug report so I don’t forget.

— Ron

[scot]

Thanks, I’ll update my config file next time I test a nightly. I hadn’t even thought about that.

Any word on the following issue?

in mt-daapd-svn-1696/src/mp3-scanner.c (version 1670) line 369 I change “if(err == -1) {” to “if(err != 0) {“

Without this change it just keeps rescanning the last file in the first directory over and over.

Yes, autoconf and libtool are nightmares. I’ve never really been able to figure them out. It was easier just to write portable code than learn those nightmares.

[rpedde]

@scot wrote:

Thanks, I’ll update my config file next time I test a nightly. I hadn’t even thought about that.

Any word on the following issue?

in mt-daapd-svn-1696/src/mp3-scanner.c (version 1670) line 369 I change “if(err == -1) {” to “if(err != 0) {“

Without this change it just keeps rescanning the last file in the first directory over and over.

Yes, autoconf and libtool are nightmares. I’ve never really been able to figure them out. It was easier just to write portable code than learn those nightmares.

K, now that it’s now that it’s on this thread, I’ll add that as well.

— Ron

[Author]

Posts