My Loxone Audioserver exposes 2 zones: Badkamer (Bathroom) and Keuken (Kitchen), but only one shows up in Roon: Keuken.
I tried several restarts of the server and checked the logs, nothing is mentioned about the missing endpoint: Keuken (Kitchen).
Note: both endpoints are exposed on the same ip, but use a different port.
Setup:
Roon Server: 2.53 (build 1544) production
Roon Server runs in a docker container
Remote: 2.53 (build 1544) production (on a Macbook Air with Apople M2 chip - Sequoia 15.5)
My Apple devices discovers all Airplay 2 endpoints exposed by my Loxone Audioserver.
Welcome to the forum and thanks for reaching out. Just to confirm here, in other apps (or on the MacBook Air), this device properly shows both zones and they are playable? I wonder if this issue could be due to the docker container, as docker can introduce some strange behavior if not configured correctly. Can you please temporarily host the Roon Server functionality on the MacBook Air and let us know if the issue also reproduces there? Thank you.
Thanks for getting back to us so quickly. We’re going to escalate this case for further investigation. As soon as we hear back, we’ll update you here. We appreciate your continued patience while we look into this.
Thanks for your patience. We’re working with development to confirm whether it’s plausible that Roon would ignore a second device announcement from the same IP if the other txt fields also match. Based on your initial screenshot, the port number is the only differentiation here - Roon might be considering the Badkamer Zone to be a duplicate based on the mDNS traffic.
As soon as we have a firm answer we’ll share the results, next steps, and any workarounds here. Thank you!
We should have a firm answer shortly, but we wanted to provide some more context to our investigation.
The issue here is quite possibly the shared persistent ID field in the Airplay2 discovery data you shared. Note that both Keuken and Badkamer share the same pi=50:4F:94:FC:AC:43 entry in your original Discovery app screenshot.
I recommend keeping one of these speakers off entirely until you’ve already opened Roon and paired with the first visible Zone (either Keuken or Badkamer). Turn on the second speaker and click the refresh button in the Roon Settings → Audio page.
We’ll share more information as soon as it’s available. Thanks!
Development is investigating this case. Thank you again for your patience.
If the team determines we can change our Airplay implementation with logic to accommodate the multiplexing used by Loxone, then we’ll include that fix in a future build. Otherwise, we’ll share any potential workarounds we might find given the control limitations of the Loxone’s networking settings.
Please stand by and we’ll respond as soon as possible.
The team has a ticket in the pipeline to address this multiplexing issue with Loxone-brand Airplay2 receivers.
In the meantime, since Apple’s own bonjour discovery service can differentiate between these speakers, here’s a potential workaround:
Select the System Output of your Mac Remote as a Zone in Roon
Use either Control Center or the Airplay icon to connect to the paired Loxone speakers
You’ll be routing through your Mac’s coreaudio mixer instead of directly from Roon, which may have implications for file quality and also mix in the system audio. However, this method should allow you to use both speakers in the meantime.
Please let us know if this helps. We’ll mark this thread Ticket In and notify you as soon as a fix has merged into an upcoming build for testing.
Thanks again for the report and for your patience.
Our apologies for the long delay in following up @Nik_Van_Looy - our development team is requesting some deeper diagnostics. To achieve this, could you please:
Perform a full reboot of your Roon Server twice
Keep your server online and connected to your network
Let us know when you’ve completed the above, and thanks again for your ongoing patience here!
Reboot doesn’t help, as i understand this is an issue with multiplexing that Loxone uses. I would assume this exact case can be mocked with the Airplay Discovery data i provided in my original post.
The two reboots that were requested are not intended to apply any fix but to install additional diagnostics that create additional log data for analysis.
Our R&D team is actively working on the fix of the issue and has added an additional layer of logging.
As mentioned by @Geoff_Coupe double restart is required to enable this logging level on your account. As soon as you perform the double restart, please let us know here.
