Sony SA-NS400 Support

[jasonlaguidice]

I've got some old Sony DLNA speakers around them and what a perfect project to stumble across for this. I'm using spotupnp-llinux-x86_64. It runs successfully and on starting discovers the speaker and volume control works.

If I start a Spotify stream I get about one second of audio and the speaker stops, disconnecting. The log output from SpotConnect looks like this:

I HTTPstreamer.cpp:441: got HTTP connection 18
I HTTPstreamer.cpp:208: HTTP received =>
GET /stream?id=bbbbf521c738_0 HTTP/1.1
Host: 192.168.1.83:59607
Icy-MetaData: 1
Connection: close
transferMode.dlna.org: Streaming
User-Agent: WinampMPEG/2.8
Accept: */*
X-AV-Client-Info: av="5.0"; cn="Sony Corporation"; mn="SA-NS400"; mv="1.00"
X-
I HTTPstreamer.cpp:310: HTTP response =>
HTTP/1.1 200 OK
transfermode.dlna.org: streaming
Server: spot-connect
Content-Type: audio/mpeg
Connection: close

I HTTPstreamer.cpp:208: HTTP received =>
AV-Physical-Unit-Info: pa="SA-NS400"

E HTTPstreamer.cpp:215: Incorrect HTTP request, can't find streamId AV-Physical-Unit-Info: pa="SA-NS400"
I HTTPstreamer.cpp:457: HTTP close 18
[18:11:21.160543] ActionHandler:617 [0x7ff04a078010]: uPNP playing
D MercurySession.cpp:251: Executing Mercury Request, type SEND
I spotify.cpp:356: current trackInfo id 253c2fb06cdf4e53ace45be0782e1163 => <Everyone's Safe In The Treehouse>
I spotify.cpp:424: track bbbbf521c738_0 started by URL (1)
I spotify.cpp:388: adjusting real position 0 from 0 (offset is -89583)
D MercurySession.cpp:251: Executing Mercury Request, type SEND
I MercurySession.cpp:42: Received packet, command: 178
D MercurySession.cpp:174: Received mercury packet
I MercurySession.cpp:42: Received packet, command: 178
D MercurySession.cpp:174: Received mercury packet
[18:11:23.397349] ActionHandler:597 [0x7ff04a078010]: uPNP stopped
I spotify.cpp:450: Disconnecting [Main Room] SA-NS400+
[18:11:23.397423] shadowRequest:339 [0x7ff04a078010]: Stop
[18:11:23.397442] AVTStop:203 [0x7ff04a078010]: uPNP stop (cookie 0xb)
I HTTPstreamer.cpp:146: HTTP streamer bbbbf521c738_0 deleted
I TrackPlayer.cpp:94: Resetting state
I MercurySession.cpp:128: Disconnecting mercury session
I PlainConnection.cpp:197: Closing socket...
E MercurySession.cpp:53: Error while receiving packet: Error in read
I TrackPlayer.cpp:249: Playing done
I spotify.cpp:577: disconnecting player <[Main Room] SA-NS400+>
[18:11:24.397182] ActionHandler:597 [0x7ff04a078010]: uPNP stopped

I believe this to be a content length issue - trying an http content length setting of -3 (or a large positive number) results in no play and the device gets stuck and needs a reboot. Settings of -1 and 0 both result in the same as shown above - a very brief play and it stops.

I get the same behavior with mp3, pcm, and wav encodings. FLAC doesn't work (likely because the device doesn't support it). Is there any steps I can take to attempt to dig into getting one of these to work?

[philippe44]

Can you try to log in sdebug (-d all=sdebug). It will be very verbose but will tell me a bit better why the Sony reports a "STOPPED" state. Is it because it really stopped or is it because it's a spurious state (UPnP is full of these) and unfortunately I interpret that as "the user has pressed "stop" on the Sony".

[jasonlaguidice]

Sure thing! Here's the full log from starting the service, to connecting while playing a song. This had music play for about 1 second again and the speaker disconnected.

sdebug.txt

Editing: I tested Logitech Media Server with the Spotty plugin and this does work but the volume controls are pretty slow to respond. Its default streaming settings worked right away with the speaker.

[philippe44]

ok, I've found the issue (I think). I'll update version in a bit (look for 0.2.4)

[jasonlaguidice]

Looking forward to it! Also note that 0.2.3 is missing the linux x86_64 versions (looks like only x86 built correctly).

[philippe44]

uploaded

[jasonlaguidice]

Fixed it and working perfectly!

[philippe44]

I'm very eager to get your feedback on stability of this project. I have a lot of users of my AirConnect project but very (very) few on this one, so any feeback is more than welcome.

[jasonlaguidice]

I'll keep you posted! Right now the only bug I see is when the speaker is set to sleep the connect & play request only has it wake up. Disconnecting and re-connecting starts it playing.

I'm running this in an LXC on Proxmox so it'll be running 24/7, I will be able to test stability pretty easily.

[jasonlaguidice]

Reporting back after some use. SpotConnect has been effectively fire-and-forget and it's been fantastic. The LXC has been running without a single issue since booting it up for the first time.

The only weirdness I've noticed at any point is some sleep/play state mismatches between what SpotConnect expects and what the speaker is ready for.

For example - if the speaker is in sleep mode (it will have an orange LED), when connecting via SpotConnect, the speaker wakes up successfully but does not start playing. If you disconnect and re-connect it starts playing just fine. If the speaker is already awake when connecting to it, it plays first try. It's been a minor nuisance but not such that it would have pushed me farther to investigate.

Additionally sometimes when playing is stopped if the speaker isn't discretely disconnected first it remains in the awake/paused state (blinking white LED). This doesn't really cause any issues, either, and the next connect/play attempt works first try.

"Ideal" would be that after some idle time the speaker is released/set to stopped so it automatically goes back to sleep and that it would be able to be awakened from sleep and start playing first try. But that's quite a bit of work just to support an old, out-dated range of speakers that they probably sold very few of :)

In the interim this has been absolutely fantastic to get the old hardware working in a modern way and I'm so grateful for it.

Pinging you, @philippe44 just in case commenting on a closed issue does not notify you.