Reply To: Different service discovery process in latest nightly build?

#9583
hawtin
Participant

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