Casting to Sonos sends format=opus to OpenSubsonic server despite MP3 transcoding setting — Sonos cannot play Opus

Support
1

App version

Production

Issue description

Playback on the phone works fine (FLAC, direct play). When casting to the Sonos speaker, every track is abandoned after 2–7 seconds and Symfonium skips to the next one. No audio. The one MP3 in the library plays on Sonos without issues, so the speaker itself and the connection are fine.

What the server logs show

The Sonos device fetches the stream URL directly from the server (UA Linux UPnP/1.0 Sonos/96.1-79270 (ZPS36)). Two configurations, two results:

  1. Renderer max bitrate = Original → no transcode parameters in the URL, server returns the raw FLAC (audio/flac, correct Content-Length, Accept-Ranges, valid fLaC header). Sonos downloads ~5 MB of the 54 MB file and gives up.
  2. Renderer max bitrate = 320 kbps → the URL Sonos requests now ends with …&v=1.13.0&c=Symfonium&f=json&maxBitRate=320&format=opus

The server honours this and returns audio/ogg (Opus). Sonos does not support Opus and gives up the same way.

The provider’s transcoding settings are set to on-the-fly, MP3, 320 kbps, and the renderer settings for the Sonos device also show MP3 — yet the request carries format=opus. Changing the format setting has no effect on what is sent for the UPnP renderer.

Workaround in place
An nginx rule in front of the server rewrites format=opus → format=mp3 for requests whose User-Agent contains Sonos/. This works, but it is a proxy-side patch for a client-side decision.

Request
Could the renderer (or provider) transcoding format setting be honoured when casting to UPnP renderers — or, given that Sonos is a known device family without Opus support, could Symfonium default to MP3 for Sonos automatically? Happy to provide Symfonium debug logs if that helps.

Device type

Phone

Media provider

Subsonic (Open)

Steps to reproduce

Replaying the exact same request against the server with format=mp3 instead of format=opus returns audio/mpeg, and Sonos plays that stream to the end (a full track downloaded as one request, 14 MB, no skip). So the only difference between failure and success is the format parameter Symfonium chooses for the UPnP renderer.

I searched existing issues first

on

I understand that logs are mandatory

on

Log upload name / description

Shanster

2

Your log is empty and does not reproduce …

But OpenSubsonic have a proper API for proper transcoding that Symfonium fully support.

LMS and Navidrome support that, you might want to ask your server to support it too.

3

Thanks — you were right, and I withdraw the report against Symfonium.

I checked the server side: DroppedNeedle actually implements the OpenSubsonic transcoding extension (getTranscodeDecision / getTranscodeStream both work when called directly — a client profile without FLAC yields canTranscode=true with mp3/320000, and getTranscodeStream returns audio/mpeg), but it does not list transcoding in getOpenSubsonicExtensions. So Symfonium never sees it and correctly falls back to the legacy format= path. I’ve filed an issue with DroppedNeedle with the one-line fix.

Apologies for the empty log — the problem turned out to be entirely on the server side, so there was nothing for Symfonium to log.

One question so I know what to expect once the server advertises the extension: when casting to a Sonos renderer, does Symfonium build the directPlayProfiles from the device’s ProtocolInfo as-is? Sonos declares FLAC support, but on this system the speaker rejected a raw 16/44.1 FLAC stream served with correct audio/flac / Content-Length / Accept-Ranges headers (while the same track transcoded to MP3 plays fine). If Symfonium passes FLAC through in the profile, the server will pick direct play and the speaker will fail the same way — in which case an MP3-only profile for Sonos on the Symfonium side would be the missing piece. Happy to provide a debug log of that specific case if useful.

4

Wrong the logs would have shown everything actually and avoided me to lose time trying to find a log and analyse it while you knew it was empty :wink: The process is about being efficient not losing time for no reason.

Anyway Symfonium is fully aware of Sonos limitations and generate the proper profiles.