Skip to main content
Hi - I asked that question a couple of years ago:

I'm using my own software to control my Sonos using UPnP for some special setup. When sending an audio file, in UPnP it's a simple webserver that handles the player's request. Sonos devices handle well, when the file is flac or wav, a HTTP transfer mode named chunked-encoding which is used when the source does/can not know the size of the file to be transmitted and just send data in chunks. Strange enough, chunked-encoding does not work with MP3 and I can't see the reason why, so the un-elegant workaround is to fake a file size and cut the HTTP connection when needed.

I was hoping that this would be corrected with new releases, but it does not seem to be or there is another reason that I'd be curious to know. I know this is not a forum for dev and Sonos has little reason to spend quality time on that, but raising a ticket does not hurt and if it ever reaches the dev team, they might want to correct that for sake of a cleaner implementation (although the Sonos' UPnP implementation is the cleanest I've seen so far)
I'm going to ask the obvious "dumb" question.



Why don't you encode all your files so they are in a working format??
It's a combination of space requirement and the fact that some sources are true live streams, so it would need to be on the fly transcoding. It's doable as well, but not my preferred solution. Today, MP3 work if I use HTTP mode with a fake, very large, content-size and I close the connection at the end of the file, but it's just a workaround
I've only used chunked encoding with wav formats, so I've never stumbled across this issue. However it do sounds like a bug (i recall someone else mentioning this a few months ago, maybe was you?).



However, have you tried using the custom mp3-radio scheme? Instead of sending a http url to the player, you could send:



x-rincon-mp3radio://someurl.com/stream



Which would use a different streaming mechanism (with greater buffering, I assume). Would increase delay, but you would get delay on the regular http scheme as well so I assume this is not for synchronized playback.
Thanks but is the "x-rincon-mp3radio" described somewhere? I don't know what the Sonos player is expecting then
Not to my knowledge. But it supports regular http hosted mp3 files, as well as shoutcast style radio stations. Just use "x-rincon-mp3radio" instead of "http" in the url you are sending to the setavtransporturi call. You might need to give it an empty DIDL block as well. If you want to simulate this, just add your stream/url to a custom radio station in the Sonos client.
Terms & ConditionsCookie settings