FireFly Media Server (formerly mt-daapd) › Firefly Media Server Forums › Firefly Media Server › General Discussion › Different service discovery process in latest nightly build? › Reply To: Different service discovery process in latest nightly build?
well, there are 3 options.
the builtin mDNS responder
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.
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:
but when I looked at the output from “mt-daapd -d9 -f” I was getting:
SocketDataReady got a packet from 192.168.254.1 to 18.104.22.168 on interface 192.168.254.200/eth0/2
Received Query from 192.168.254.1 :5353 to 22.214.171.124 :5353 on 0x08096E20 with 1 Question, 0 Answers, 0 Authorities, 0 Additionals
SocketDataReady ignored a packet from 192.168.254.1 to 126.96.36.199 on interface /2 expecting 192.168.23.200/eth1/3
SocketDataReady ignored a packet from 192.168.254.1 to 188.8.131.52 on interface /2 expecting 192.168.71.200/eth2/4
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:
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.