@eschoeller wrote:
creating a static entry did not resolve the issue.
To be more specific, the service appears in iTunes after mt-daapd is restarted, but if iTunes is closed and re-opened, it does not appear.
That’s unquestionably a firewall issue. What happens is when the server registers, the mdns daemon pre-caches listening mdns clients by announcing startup. The mdns clients resolvers are supposed to cache that announcement. So when iTunes is open and you start mt-daapd, you see the pre-cache announcement.
If you close iTunes and start iTunes, iTunes does an mdns-sd query. If it gets no response from the server, then it shows up nothing.
Since it’s clear the server can send packets (since it shows up when it starts up), it must be that is doesn’t see the mdns-sd query. Usually that’s a firewall issue, since many firewalls forget that 224.0.0.0/4 are local addresses (certainly 224.0.0.0/24 are, anyway).
I’ve been here before with my last install, it always seems that it is a miracle when mDNS is working reliably.
Probably because everyone else uses broadcast resolutions since multicast seems so universally overlooked/broken.
Some services need to explicity be told to bind to the alias IP, so they don’t try to bind to 0.0.0.0 or 127.0.0.1.
I don’t think that’s the case here — it’s sending packets, so the networking can’t be totally broken.
How does the networking work on that? Is the vserver interface a bridged interface, or something like that?