mirror of
https://github.com/lox-audioserver/lox-audioserver.git
synced 2026-04-26 06:45:47 +03:00
[GH-ISSUE #119] Sonos Output - S1 and S2 are not compatible...Grouping not possible. #64
Labels
No labels
bug
enhancement
pull-request
released
released on @beta
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/lox-audioserver#64
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @simon2207 on GitHub (Jan 16, 2026).
Original GitHub issue: https://github.com/lox-audioserver/lox-audioserver/issues/119
Got one Idea today...
I bought a cheap Sonos Connect S1 Version from Ebay and implemented that into my network
with the old Sonos S1 App from the IOS App Store. After cabling that to my Test FOSI Amp I can listen to some vinyl from my turntable through the amp and some passive speakers.
BUT even I was able to add that Sonos Connect to my Lox Audioserver: Branch v4.0.0-20260111152632 - from the Zones Feature... there
wasn´t any music playing after grouping that Sonos Connect with my Sonos Living Room ( S2 Devices )...
So - maybe I m doing something wrong here - or S1 and S2 are not the same technic or working differently in the background.
Its a bit that, because I don't want to spent that much money on an Sonos S2 AMP only to get my Turntable into the loop.
2026-01-16T19:35:24.085Z][INFO][Groups|Manager] [externalId=grp-25-1768591409073 leader=25] group removed
[2026-01-16T19:35:24.356Z][INFO][Transport|Sonos] [action=BecomeCoordinatorOfStandaloneGroup service=AVTransport zoneId=22] Sonos action succeeded
[2026-01-16T19:35:28.072Z][INFO][Groups|Manager] [externalId=grp-25-1768592128072 leader=25] group created
[2026-01-16T19:35:28.095Z][WARN][Transport|Sonos] [action=SetAVTransportURI body="<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><s:Fault>s:ClientUPnPError<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">501</s:Fault></s:Body></s:Envelope>" service=AVTransport status=500 zoneId=14] Sonos action returned SOAP fault
[2026-01-16T19:35:41.117Z][WARN][Transport|Sonos] [action=SetVolume body="<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><s:Fault>s:ClientUPnPError<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">501</s:Fault></s:Body></s:Envelope>" service=RenderingControl status=500 zoneId=25] Sonos action returned SOAP fault
[2026-01-16T19:35:41.117Z][INFO][Transport|Sonos] [volume=34 zoneId=25] Sonos volume set
[2026-01-16T19:35:42.103Z][WARN][Transport|Sonos] [action=SetVolume body="<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><s:Fault>s:ClientUPnPError<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">501</s:Fault></s:Body></s:Envelope>" service=RenderingControl status=500 zoneId=25] Sonos action returned SOAP fault
[2026-01-16T19:35:42.104Z][INFO][Transport|Sonos] [volume=34 zoneId=25] Sonos volume set
[2026-01-16T19:35:43.057Z][WARN][Transport|Sonos] [action=SetVolume body="<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><s:Fault>s:ClientUPnPError<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">501</s:Fault></s:Body></s:Envelope>" service=RenderingControl status=500 zoneId=25] Sonos action returned SOAP fault
[2026-01-16T19:35:43.058Z][INFO][Transport|Sonos] [volume=32 zoneId=25] Sonos volume set
@rudyberends commented on GitHub (Jan 18, 2026):
Your title already sums it up well: S1 and S2 are not compatible.
They are fundamentally different platforms and cannot be synchronized using any native Sonos protocol.
At the moment, lox-audioserver only supports protocol-based grouping. This means grouping relies entirely on the capabilities of the underlying output protocol to handle synchronization. For now, this is the main focus until the first stable release. After that, we can evaluate additional approaches.
In previous versions, it was possible to create groups containing mixed output protocols. This could be confusing, because although the group was created successfully, no audio would be heard. For this reason, the latest (beta) release no longer allows grouping members with different output protocols. Any member whose output protocol differs from the group master will not be allowed to join the sync group.
As you mentioned earlier, there are two other possible grouping concepts:
Playing the same content to all members in such a group is not an issue. Achieving proper synchronization, however, is a completely different problem and will always be best-effort at best. Music Assistant does this using so-called universal groups. I may look into this, but I am not yet convinced it is worth the development effort, given that the result can never be fully reliable.
At this point, I honestly do not know how this works. We would need to determine which protocol is used for synchronization between audio servers. It could be LMS-based, but it could also be proprietary. This would require packet captures between audio servers to inspect the traffic. If you are willing to provide such traces, I can investigate whether this is feasible.
Finally, regarding your turntable:
You may want to try the latest beta release, which now includes line-in support. Do note that this requires hardware with actual line-in capabilities.
@simon2207 commented on GitHub (Jan 23, 2026):
Hi @rudyberends,
im still on v4.0.0-20260111152632 - any update on the docker testing branch?
Turntable - I m going to spent some money for a Sonos AMP to get it into the sonos ecosystem and later via lox-audioserver to combine them with the Loxone in ceiling system.
Regarding your audio server traces - if I knew how to do that, I may be able to investigate that from my site.
@rudyberends commented on GitHub (Jan 23, 2026):
From now on, testing builds are created only to investigate or troubleshoot a specific issue.
They may contain extensive debug logging, experimental changes, and are not guaranteed to be stable.
These builds are primarily intended for my own testing or for users who are explicitly asked to test a particular problem against a specific version.
Beta releases are intended for general testing of the latest features and fixes.
They are expected to be usable in normal test environments and represent the current development state leading up to a stable release.
This pull/tag will always point to the latest beta build.
The current version is beta2, but I will release a version 3 probably tomorrow
docker pull ghcr.io/rudyberends/lox-audioserver:beta-latestBeta versions show up under releases as prerelease
@rudyberends commented on GitHub (Jan 25, 2026):
I’ve released beta3, which now also includes support for mixed groups.
Mixed groups allow members with different output protocols to be grouped together. Playback synchronization in these groups is best effort: each zone plays the stream independently, without any shared clock or guaranteed sync.
This feature must be explicitly enabled. By default, the server will still drop group members whose protocol does not match the group master’s protocol.
@simon2207 commented on GitHub (Jan 25, 2026):
@rudyberends just to let you know - I was unable to run the beta 3 container on my Synology - first time I experienced some port errors... Did you changed some ports between beta 2 and 3?
[2026-01-25T11:59:23.172Z][ERROR][Server] [message="listen EADDRINUSE: address already in use 0.0.0.0:3483"] fatal bootstrap error
Container constantly restarts...
Might be a conflict between MusicAssistant and Lox-Audioserver.
I tried:
docker run -d
--name=lox-audioserver
--restart=always
-p 13483:3483
-e TZ=Europe/Berlin
-v /volume1/docker/lox-audioserver/data:/app/data
ghcr.io/rudyberends/lox-audioserver:beta-latest
-p 13483:3483 instead of
--network host \
but now I m stuck and unable to open the web interface. so I switched back to
--network host
and stoped the Music Assistant Container to get it up and running... but now I m only able to use Apple Music while Spotify provided by Music Assistant is not possible...
anyway - the new beta 3 look and feel is really nice! thank you.
@rudyberends commented on GitHub (Jan 25, 2026):
Ah, yes — that’s the new Squeezelite/SlimProto service binding to port 3483. That wasn’t implemented in previous versions, which is why you didn’t hit this conflict before.
Unfortunately we cannot change this port as those clients are using an udp port discovery on exactly that port. Changing it would prevent auto discover.
I will update the code to not stop when a non essential port is in use, but you will loose Squeezelite functionality if it cannot start.
@simon2207 commented on GitHub (Jan 25, 2026):
@rudyberends Thanks for that explanation - right now I m fine with skipping music assistant in total. Lox-Audioserver is doing everything important and I don't need music assistant since version 4.x.
@rudyberends commented on GitHub (Feb 1, 2026):
I am closing this one for now, as grouping with mixed groups is now possible. This leave us only with groups across audioservers. There is another one open for that.