Sonos Play:3 announcements corrupt active music stream (ERROR_CORRUPT_FILE)

[bthornton191]

What version of Music Assistant has the issue?

2.7.11

How is the MA server installed?

Docker Container

Mandatory: Carefully read the Troubleshooting FAQ and confirm that

• I have examined the logs and tried to resolve this issue
• I have fixed any errors or warnings in the logs that relate to tags
• I am not running MA across a VPN, VLAN, subnet, behind a firewall, or using local SSL or have any other complex network setup
• I am not using or have disabled tools such as AdGuard, Pi-hole or pfSense and retested
• I have checked my network setup to ensure mDNS/multicast is not being blocked
• I have reviewed the Open and Closed Issues and Discussions
• I have reviewed the applicable player or music provider documentation
• I have reviewed the MA Status Page
• I have tried restarting MA and rebooting the host

As Applicable: Carefully read the Troubleshooting FAQ and confirm that

• If using HA, I have confirmed the internal URL is set correctly
• I have tried a wired connection for issues related to interrupted or poor playback quality
• If the problem relates to a device then I have checked the device settings
• If it is a frontend issue, I have tried a different widely used browser
• For voice problems, I have sought help elsewhere before returning here
• For playback problems, I have recycled power to the physical device

The problem

Description

Sonos Play:3 (model S3) exhibits the identical ERROR_CORRUPT_FILE stream corruption behavior as Play:1 when announcements are played via the native loadAudioClip / play_audio_clip API while music is actively streaming.
This is a follow-up to #4548, where developer @MarvinSchenkel explicitly asked:

"Thanks for testing on the play:5, I was wondering if this could affect the entire play:X series. If anyone still has a play:3 and could test this, then I could also include that in the fix if that does not work."

The answer is yes — Play:3 has the same problem.

Environment

• MA version: 2.7.11
• HA version: 2026.3.2
• Sonos model: Play:3 (model number S3, firmware 86.4-73290)
• Deployment: Docker, host network mode

Symptom

When a TTS announcement is sent to a Play:3 that is actively streaming music from an MA queue, the following occurs every time:

1. Announcement triggers play_audio_clip (native Sonos loadAudioClip API)
2. The active music stream is abruptly disconnected within 0.1–3 seconds ("Kitchen disconnected prematurely from [track]" warning)
3. ERROR_CORRUPT_FILE is reported for the interrupted track
4. Sonos attempts to advance to the next track, which also fails — cascading ERROR_CORRUPT_FILE errors follow
   Announcements to the same Play:3 when it is not streaming music succeed without any errors.

Log Evidence

11:42:33.434 INFO Playback announcement to player Kitchen: http://.../api/tts_proxy/....mp3
11:42:33.619 WARNING Kitchen disconnected prematurely from "What Will Be" (sent 13,528,545 of ~60,878,109 bytes)
11:42:40.588 ERROR ConnectionResetError in serve_announcement_stream
11:42:41.875 ERROR ERROR_CORRUPT_FILE for "What Will Be"

How to reproduce

1. Have a Sonos Play:3 (model S3) connected as a player in Music Assistant (S2 provider)
2. Start playing a music queue on the Play:3 through MA (any source — local files, YouTube Music, etc.)
3. While music is actively streaming, send a TTS announcement to the Play:3 via HA:

   service: tts.speak
   data:
     media_player_entity_id: media_player.kitchen  # MA player entity for the Play:3
     message: "This is a test announcement"
   target:
     entity_id: tts.piper

4. Observe in MA logs:
   • Playing announcement ... on Kitchen (native play_audio_clip path)
   • Player Kitchen disconnected prematurely from stream for [track name] within 0.1–3 seconds
   • ERROR_PLAYBACK_FAILED / ERROR_CORRUPT_FILE for the interrupted track 5–25 seconds later
   • Subsequent tracks in the queue also fail with ERROR_CORRUPT_FILE
     Expected behavior: Announcement plays and music resumes normally (as it does on Sonos One, Era 100, Beam, etc.)
     Actual behavior: The native loadAudioClip API corrupts the active HTTP stream. This is identical to the Play:1 behavior fixed in PR Fix announcement for Sonos Play:1's server#3009 — Play:3 just needs to be added to UNSUPPORTED_MODELS_NATIVE_ANNOUNCEMENTS in music_assistant/providers/sonos/const.py.
     Note: Announcements to the same Play:3 when it is not streaming music succeed without errors.

Music Providers

file system

Player Providers

Sonos

Full log output

ma_20260323T114233_20260323T122000.log

Additional information

Playback instigated via: HA service call (tts.speak with tts.piper targeting MA media player entities). Also reproducible with voice satellite wake/done sounds triggered from a tablet integration.

Network setup: Standard flat LAN, no VLANs/VPNs/subnets. Both MA and HA run in Docker with network_mode: host on the same server (192.168.5.62). Play:3 is wired ethernet. mDNS/multicast works correctly (Sonos discovery has no issues).

Not running HAOS — this is a standalone Docker Compose deployment on Linux.

What I've tried / ruled out:

• Restarted MA container and verified issue persists across restarts
• Confirmed the issue is 100% reproducible: every announcement to the Play:3 while music is streaming causes ERROR_CORRUPT_FILE; every announcement when music is NOT streaming succeeds
• Confirmed announcements to other speakers (e.g., Fitz's Room, not a Play:X model) work fine even during active streaming
• Enabled debug logging and captured the full flow — ffmpeg successfully fetches and serves the announcement audio; the corruption is on the music stream side, not the announcement stream
• Verified this is not a network, DNS, or TTS proxy issue — the tts_proxy URLs are valid for 5 minutes and support multiple fetches

Root cause identified: Play:3 reports SonosCapability.AUDIO_CLIP and is not in UNSUPPORTED_MODELS_NATIVE_ANNOUNCEMENTS (only "Play:1" is listed), so MA uses the native play_audio_clip / loadAudioClip path. This is the same code path that was disabled for Play:1 in PR music-assistant/server#3009 due to identical ERROR_CORRUPT_FILE behavior. The developer explicitly asked in #4548 whether Play:3 was also affected — this confirms it is.

Previous MA version: Was running 2.7.3 (where announcement handling was different). Issue appeared after upgrading to 2.7.11, crossing the 2.7.6 boundary where PR #3009 changed the announcement architecture.

Proposed fix: Add "Play:3" to UNSUPPORTED_MODELS_NATIVE_ANNOUNCEMENTS in music_assistant/providers/sonos/const.py, same as Play:1.

What version of Home Assistant Core (if used) are your running

2026.3.2

What type of installation are you running?

Home Assistant Container

On what type of hardware are you running?

Proxmox

Have you included ALL of the information specified in the Troubleshooting FAQ or explained why you cannot

• Yes

[MarvinSchenkel]

Will be fixed in 2.8

[MarvinSchenkel]

2.8 has been released. Can you please check if this issue is fixed?

[OzGav]

This will be closed soon due to no follow up

[bthornton191]

Confirmed fixed in 2.8.1.

Tested TTS announcement (tts.speak via Piper) to Play:3 while actively streaming music.

The announcement used the fallback path, music resumed normally afterward. No ERROR_CORRUPT_FILE, no premature disconnects.

Thanks for the quick fix!