Add manual IP addresses setting to the Airplay provider

[staticdev]

This PR adds the shared manual discovery setting to the AirPlay provider for networks where mDNS discovery cannot reach AirPlay devices. Entries are intentionally limited to plain IP addresses or hostnames; Music Assistant resolves them and probes the default AirPlay/RAOP /info endpoints on ports 7000 and 5000 to build normal AirPlay discovery metadata. A stable device ID is required so manually discovered players keep the same AirPlay player ID and do not duplicate if mDNS later starts working.

Similar change to: #3846
Docs: music-assistant/music-assistant.io#661

[staticdev]

Could you please take a look @bradkeifer @maximmaxim345?

[bradkeifer]

Looks pretty good to me. I think it would be appropriate to allow the port number to be user configurable, with defaults as you currently have. I recall an issue raised a few months ago where someone had a device that did not use the default port of 5000 for raop and 7000 for airplay2.

[marcelveldt]

This does not make a lot of sense to me and I'm against adding this.
AirPlay is by default completely based around mdns and we even need to read properties from mdns to offer things like encryption and pairing. In a normal domestic network setup, mdns will work fine.

Trying to use these protocols in an environment is was never intended for (e.g. enterprise grade networks) will just give issues.

Adding this will hurt more than it solves imo.

[marcelveldt]

see my comment - I dont think this is a good idea to add at all

[staticdev]

@bradkeifer That would be a simple change to make, I just did not add since the PR was already with a considerable size for reviewing, the extra parsing would just make it a bit longer. But now I am worried I spent my effort in vain if @marcelveldt is not onboard.

I agree that mDNS should remain the default and recommended AirPlay setup. I am not trying to change that, or suggest that manual/static AirPlay setup should be the normal path.

The use case I am trying to solve is narrower: home users who intentionally isolate IoT or media devices on another VLAN, but still want to allow Music Assistant to stream to a known AirPlay target. This is not only an enterprise setup anymore; UniFi, Omada, pfSense, OpenWrt, etc. have made segmented home networks quite common, especially for TVs and other devices people do not fully trust.

From a security point of view, manually adding one known AirPlay device can actually be cleaner than enabling broad mDNS reflection across VLANs. With mDNS reflection, discovery traffic and advertised services are shared more widely. With manual configuration, the user can allow only MA -> specific device IP/ports in the firewall.

I fully understand that AirPlay depends on mDNS TXT properties for things like encryption, pairing and capabilities. So I do not think this should bypass those requirements blindly. A reasonable compromise could be:

• keep mDNS discovery as the normal and recommended path
• make manual AirPlay targets an advanced/opt-in option
• treat them as best-effort
• fail clearly if the required properties/capabilities are missing
• document that this is for users who understand their network setup
• avoid adding support burden for broken enterprise networks

The reason I think this is worth considering is consistency with the rest of Music Assistant. Today it is already possible to use isolated devices with protocols like Google Cast, MPD, Sendspin, Sonos, Roku and WiiM when the network is configured intentionally. AirPlay is currently the odd one out, even for simple cases like a Samsung TV with AirPlay support that the user wants to include in party mode.

So I agree with the concern that we should not encourage unsupported or fragile AirPlay deployments. But I think an advanced, explicit, manual option would solve a real home-network use case without changing the default behavior or weakening the mDNS-based implementation for normal users.

[marcelveldt]

We state clearly in our documentation that we do not support advanced network deployments like vlans etc. and both MA and the speakers must be on the same (v)LAN.

If you want to isolate your speakers and/or IoT devices from your main network, an easy fix is to simply put MA on that same (v)LAN or even make the host multi homed. We offer advanced settings to set the bind addresses and publish addresses for this purpose.

By far the most support issues come from people with non standard network or host setups. It's simply not fair in comparison to put this strain on mostly community volunteers providing support so I think as a project we have the right to be reluctant to supporting these kind of setups. In the end the people that really know what they're doing will figure it out anyways.

For simpler protocols like Sonos and Cast we already provide this manual IP option because those are much simpler. You just need the IP to connect to and done. AirPlay is different because the entire protocol is mdns based. If we accept this manual addresses, the next thing that will happen is issue reports that people can not pair their devices etc. Also DACP will stop working (for routing commands from player to server). Long story short: It will not work properly and it will be a support nightmare.

I'm sorry for the efforts already put in this PR but we simply can not merge everything.

[staticdev]

Thanks for the detailed explanation, @marcelveldt. I understand the project boundary better now, especially the concern around support load for advanced network setups and the AirPlay-specific issues around mDNS, pairing and DACP. The last thing I want is to add strain to the MA maintainers or community volunteers.

My motivation was mainly: I work with security and segmented networks full-time, and in my own home setup I am still looking for a MA deployment model that I am fully comfortable with. Putting MA directly on my IoT VLAN would mean extra hardware and power usage in my case, so I started exploring whether a manual option could help.

This also came from seeing other users discuss on Discord similar needs, first around Sendspin, and later while talking with @maximmaxim345 and @bradkeifer about whether something similar could make sense for AirPlay. But I see now that AirPlay has deeper protocol assumptions than the simpler IP-based integrations, and that this PR touches broader support concerns.

I’ll move this back to draft for now and rethink/test this and other approaches more carefully before pushing further. I appreciate the clear feedback.

Fijne week!