The problem
Music Assistant registers four parallel player bridges for a single physical Sonos speaker (a Sonos Beam in my case) that supports multiple protocols. All four are enabled: true in settings.json out of the box, despite the Sonos player-support docs implying that AirPlay/DLNA variants for Sonos devices should be deduplicated.
The four concurrent bridges — each independently subscribing, probing, and keeping sessions alive — put the Sonos Beam into a sensitized state where routine network events (UPnP event subscriptions from HA, SSDP M-SEARCH responses, etc.) cascade to a media-pipeline refresh. On a Beam operating as a TV soundbar via HDMI-ARC/eARC, the media-pipeline refresh manifests as a brief ARC disconnect → TV (LG OLED in my case) retriggers its Dolby Vision handshake → "Resume playback" banner.
Ungraceful shutdown of MASS (docker stop) leaves residual subscription/session state on the Beam that continues to cause the same drops at a lower frequency for many hours or until the device is factory-reset. Factory-resetting the Beam dropped my TV-disruption rate from "every 4 minutes" to "every 45 minutes" (residual household/cloud-level state still present on the Five + Move, I suspect).
Setup
- MASS 2.8.5 (Docker container,
ghcr.io/music-assistant/server:latest, network_mode: host)
- HA 2026.4.1 (container) with Sonos integration already running for a long time
- Sonos household: Beam (HDMI-ARC to LG OLED + Apple TV 4K), Sonos Five, Sonos Move
- Spotify Premium configured as music provider in MASS
settings.json players for the Beam
From the MASS settings file, right after onboarding:
ap347e5c9c5b47 provider=airplay enabled=True "Family Room"
spb_347e5c9c5b47 provider=sendspin enabled=True "Family Room (AirPlay)"
RINCON_347E5C9C5B4701400 provider=sonos enabled=True "Family Room"
uuid:RINCON_347E5C9C5B4701400_MR provider=dlna enabled=True "Family Room - Sonos Beam Media Renderer - RINCON_347E5C9C5B4701400"
Expected: the three non-Sonos bridges should be disabled for Sonos-protocol devices (per docs), OR at minimum there should be deduplication by physical-device identity (MAC / RINCON UUID).
Evidence
tcpdump on HA host, host→Beam traffic during MASS runtime shows:
uuid:RINCON_347E5C9C5B4701400_MR UPnP subscriptionsap347e5c9c5b47 AirPlay keep-alives and service discoveryspb_347e5c9c5b47 Sendspin audio-bridge WebSocket probes- Native Sonos protocol subscriptions from the core provider
All four paths are active simultaneously, so for one physical speaker MASS is running ~4× the state management overhead.
tcpdump on HA host, host↔Beam traffic after MASS shutdown but before factory reset shows repeated burst responses from the Beam to HA's SSDP discovery socket — the Beam is reacting heavily to routine network events because of residual state.
Post-factory-reset of the Beam, the same SSDP response bursts still happen (can't stop HA's SSDP), but no longer cascade to HDMI-ARC drops. The TV stays stable. This confirms the sensitizing state was local to the Beam's non-volatile storage.
Reproduction
- Have an HA install with Sonos integration already working for a Sonos device that uses HDMI-ARC to a TV.
- Install MASS, add the same Sonos account.
- Observe: MASS creates a Sonos, AirPlay, DLNA, and Sendspin player all for the one physical Beam.
- Leave MASS running for some minutes. Watch the TV: HDMI-ARC disruptions start (model-dependent, most prominent on LG OLED with Dolby Vision).
docker stop MASS.- Disruptions continue at a lower rate for many hours.
- Only a factory-reset of the Sonos Beam fully resolves the sensitized state.
Requested changes
- Deduplicate player bridges by physical-device identity. When MASS discovers the same physical device via multiple protocols (e.g. mDNS AirPlay + SSDP Sonos + UPnP/DLNA), surface one player with a protocol chip, and disable/suppress the duplicate backends by default.
- For Sonos-specifically: the docs already state the intent to disable AirPlay/DLNA for Sonos devices. The implementation doesn't appear to be applying that in 2.8.5 (or has regressed).
- Ensure graceful shutdown sends UPnP UNSUBSCRIBE and cloud-session teardown for every active session. SIGTERM handling should give the Sonos provider time to tear down cleanly.
- Consider whether the 4-parallel-bridge default is appropriate for Sonos devices at all, given that Sonos's own protocol is fully functional and the others are redundant.
Related
The problem
Music Assistant registers four parallel player bridges for a single physical Sonos speaker (a Sonos Beam in my case) that supports multiple protocols. All four are
enabled: trueinsettings.jsonout of the box, despite the Sonos player-support docs implying that AirPlay/DLNA variants for Sonos devices should be deduplicated.The four concurrent bridges — each independently subscribing, probing, and keeping sessions alive — put the Sonos Beam into a sensitized state where routine network events (UPnP event subscriptions from HA, SSDP M-SEARCH responses, etc.) cascade to a media-pipeline refresh. On a Beam operating as a TV soundbar via HDMI-ARC/eARC, the media-pipeline refresh manifests as a brief ARC disconnect → TV (LG OLED in my case) retriggers its Dolby Vision handshake → "Resume playback" banner.
Ungraceful shutdown of MASS (
docker stop) leaves residual subscription/session state on the Beam that continues to cause the same drops at a lower frequency for many hours or until the device is factory-reset. Factory-resetting the Beam dropped my TV-disruption rate from "every 4 minutes" to "every 45 minutes" (residual household/cloud-level state still present on the Five + Move, I suspect).Setup
ghcr.io/music-assistant/server:latest,network_mode: host)settings.jsonplayers for the BeamFrom the MASS settings file, right after onboarding:
Expected: the three non-Sonos bridges should be disabled for Sonos-protocol devices (per docs), OR at minimum there should be deduplication by physical-device identity (MAC / RINCON UUID).
Evidence
tcpdumpon HA host, host→Beam traffic during MASS runtime shows:uuid:RINCON_347E5C9C5B4701400_MRUPnP subscriptionsap347e5c9c5b47AirPlay keep-alives and service discoveryspb_347e5c9c5b47Sendspin audio-bridge WebSocket probesAll four paths are active simultaneously, so for one physical speaker MASS is running ~4× the state management overhead.
tcpdumpon HA host, host↔Beam traffic after MASS shutdown but before factory reset shows repeated burst responses from the Beam to HA's SSDP discovery socket — the Beam is reacting heavily to routine network events because of residual state.Post-factory-reset of the Beam, the same SSDP response bursts still happen (can't stop HA's SSDP), but no longer cascade to HDMI-ARC drops. The TV stays stable. This confirms the sensitizing state was local to the Beam's non-volatile storage.
Reproduction
docker stopMASS.Requested changes
Related