Different service discovery process in latest nightly build?

[hawtin]

I have a screenless Linux box that manages my network. I also have a new Pinnacle SoundBridge (which won’t use DAAP and hence I need to build the nightly source). When I build the latest Firefly server it does not respond to broadcasts, so nothing sees it (not even the old PC clients that used to read DAAP quite happily from the 0.2.5 release).

On the configure web page it tells me that the “Bonjour” server is not running (and why should it be?). By default the new version seems to use mdns with an option to switch to avahi to control the advertising of the service. My box uses an older libc that the most recent unstable Debian packages and I am having real trouble building and configuring what is needed.

What I really would like is a build that broadcasts its services like the last stable release (0.2.5) but supports RSP protocol. Can I setting configure flags appropriately?

If not where should I look in the source code to either stitch the RSP support into the stable version or (better) to enable the old multicast support in the nightly build?

[fizze]

well, there are 3 options.

the builtin mDNS responder
bonjour
avahi

You can compile with each, with a configure option….
I do have no clue about compatibility issues regarding libc or other deps that might fail…

just our of curiousity: what kind of box do you use? just an old stand-alone PC or something embedded like a NSLU?

[hawtin]

@fizze wrote:

well, there are 3 options.

the builtin mDNS responder
bonjour
avahi

You can compile with each, with a configure option….
I do have no clue about compatibility issues regarding libc or other deps that might fail…

Thanks for the hint, I have tracked down the issue and resolved it. I will document what I did further down this message in the hope that it will save someone time later.

@fizze wrote:

just our of curiousity: what kind of box do you use? just an old stand-alone PC or something embedded like a NSLU?

Neither, I bought a box from Soekris. It is a great little piece of kit with 3 network ports and space for a laptop drive in a fanless case (which strangely always feels colder than room temperature). I have installed Debian and use it as a DMZ/ internal network firewall, Windows domain controller, mail server, DNS, timeserver, file server, internal web server and music server.

I tried the option to build with the “builtin mDNS responder” by using the command:

./configure --enable-sqlite

but when I looked at the output from “mt-daapd -d9 -f” I was getting:

select(9, 127.889648)

SocketDataReady got a packet from 192.168.254.1 to 224.0.0.251 on interface 192.168.254.200/eth0/2

Received Query from 192.168.254.1  :5353 to 224.0.0.251    :5353 on 0x08096E20 with  1 Question,   0 Answers,  0 Authorities,  0 Additionals

SocketDataReady ignored a packet from 192.168.254.1 to 224.0.0.251 on interface /2 expecting 192.168.23.200/eth1/3

SocketDataReady ignored a packet from 192.168.254.1 to 224.0.0.251 on interface /2 expecting 192.168.71.200/eth2/4

select(9, 0.110351)

but the server was just failing to reply to any of the request. I tried to build with either avahi or Bonjour but configuring them was just too hard (not having a screen on the server I don’t have Qt installed).

It turned out that my lack of responce was down to the “make install” command not writing a new configuration file. The latest build rely on the configuration lines:

[plugins]

plugin_dir = /usr/local/share/mt-daapd/plugins

If this is not in the configuration file then the server will only respond to the web requests. I was not careful enough about checking what the install had done.

This mistake was clearly my own fault but a couple of adjustments would make this great piece of software even better.

The “status” page should show a list of the active plugins and complain if there are no plugins configured. Also the startup should check that at least one server plugin is active and give a message if none can be found.

[fizze]

ok.
This is probably the most common cause when moving from “stable” to the “nightlies”.

the config file should be overwritten and freshly adopted.
in the nightlies, every audio stuff, DAAP, RSP, etc. is plugin-ified.
And mt-daapd executes and loads every plugin it can find, in the plugin dir, by default.
So this explains why its “just” listening on the web-port-thingy.

I agree, it would be nice to have some sort of complaint about a missing plugin dir, and also a list of plugins that are currently active, and overall present, prolly.

Some of those Soekris products look nice. (Deep) embedded thingies with a nice case rock. Wish you could get those over here in good ol’ Europe. *Sigh* 😉

[hawtin]

@fizze wrote:

Some of those Soekris products look nice. (Deep) embedded thingies with a nice case rock. Wish you could get those over here in good ol’ Europe. *Sigh* 😉

I’m in the UK. I mail-ordered direct from Soekris in the US (there is a place in Holland but the mark-up is too much). Even with the £50 additional VAT charge it seemed like good value (the dollar being so week at the moment).

The service was really good (in my case it took four days for delivery)

[Author]

Posts