500 when trying to play from spotify

[johnnyfleet]

I've been trying to troubleshoot playback issues recently with my Sonos and this program. I use it as part of https://github.com/ryanolf/node-sonos-nfc to read nfc tags and play music. I think it has been having issues for a while but spent the weekend troubleshooting, but appreciate wider support to help. It used to work fine - but I acknowledge that Sonos update screw ups have caused no end of issues - so I'm trying to figure out if there is something that can be fixes to make work again.

To isolate the issues I've been running just the node-sonos-http-api program locally using npm start.

Problem

❌ I seem to be unable to lookup or play music from Spotify.

Example: Trying to play One by One by Foo Fighters. The spotify link is https://open.spotify.com/album/1zQ6F8gMagKcPL4SoA80cx?si=zfp9lWkxQfKrgLO_X6Qo6Q. Following the rough advice from here I have crafted the album URI as:

spotify:album:1zQ6F8gMagKcPL4SoA80cx

I've then constructed into a URL to play locally on a Roam 2: http://localhost:5005/Roam%202/spotify/now/spotify:album:1zQ6F8gMagKcPL4SoA80cx

However I get the following error returned:

{
"status": "error",
"error": "Got status 500 when invoking /MediaRenderer/AVTransport/Control",
"stack": "Error: Got status 500 when invoking /MediaRenderer/AVTransport/Control\n    at Object.invoke (/home/john/Development/node-sonos-http-api/node_modules/sonos-discovery/lib/helpers/soap.js:99:10)\n    at Player.addURIToQueue (/home/john/Development/node-sonos-http-api/node_modules/sonos-discovery/lib/models/Player.js:616:15)\n    at /home/john/Development/node-sonos-http-api/lib/actions/spotify.js:33:36\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)"
}

What does work?

I have confirmed that:

• ✅ Playing music from my local library (through favourites) works flawlessly. http://localhost:5005/Roam%202/favourite/Phil%20Collins
• ✅ Pausing the player works no issue http://localhost:5005/Roam%202/pause
• ✅ Resuming playback works no issue http://localhost:5005/Roam%202/play

Spotify Credentials setup

I have created a settings.json file in the root project with spotify details. It seems the spotify developer portal has changed a little so the info in readme a little ambiguous. I set up with the following details:

I assume the redirect isn't needed. I didn't know the required scope so I assumed Web API.

The settings.json file simply looks like:

{
  "spotify": {
    "clientId": "<redacted-for-github>",
    "clientSecret": "<redacted-for-github>"
  }
}

Any suggestions to help greatly appreciated.

[ashenshugarRET]

Hello, the issue lies with the fact that you are using the localhost reference to your computer (Raspberry Pi??) within your URL. I'm assuming you are entering this into a web browser on a different computer on your network; in this scenario, localhost won't work. You need to change localhost to the IP address of the computer on which you are running this repository.
I've tested the URL you created, changing localhost to the IP address of my Raspberry Pi (192.168.1.4 in my case), and it worked perfectly.
Using localhost works when using node-sonos-nfc directly as that is usually running on the same computer.

[jishi]

The credentials setup is only used for the music search feature. Directly referencing a spotify uri (and play using /spotify/now/xxxxx ) is usign the credentials you've added into the Sonos system, however I'm not certain on how this work with a multi-user setup nowadays (it was a long time ago since I've used this).

The 500 error is from the Sonos player, and can mean anything from invalid parameters to an invalid request altogether, so there is no more help to get from the actual player or the logs.

When I try your link, it works on my system though, so not sure about the cause.

[johnnyfleet]

Hmm ok, thanks both.

So it seems the credentials I can skip then and rule out. I have tried not using localhost (I have a raspberry pi with the nfc app with this built in and same behaviour. So I don't think it's the localhost issue.

I even tried switching to different speaker as the target (linked to same account).

So i guess I need to narrow down something more with the Sonos system. I'll have to experiment some more this weekend. Good to know that the Spotify links work for both of you - so it's well formed, just something most likely on the Sonos side, or the link between.

Do you know of any ways to get additional logging information from Sonos, or making this morning verbose?

[jishi]

There is no way to make the logging from Sonos more verbose, but you can make the api more verbose by running with the env variable NODE_LOG_LEVEL=debug or even trace to give you exactly what it tries to send to the players.

Is your system running S1 or S2? Are you sure that your Spotify credentials work properly in Sonos? I assuming you can playback Spotify normally through the Sonos app?

[johnnyfleet]

Thanks I'll give it a try to increase logging. I am using S2 system.

Spotify works...most of the time. Let's be honest, this past year has been a cluster for ongoing issues.

I might just try a factory reset at the weekend of the Sonos to see if that kicks it into life, especially if you have had success playing.

A possible complication, I have Spotify family plan so I have one account for Sonos and another as my primary on phone. That way we don't end up stopping playback.

When I set up I'm careful to select the right account, but I'll recheck as maybe that could cause it. Though from what you describe it shouldn't matter. Ifs just sending the URI and Sonos sorts the rest with Spotify right?

[jishi]

I'm on S1 still since half of my hardware is too old, so can't really speak for S2.

Yes, when you queue a spotify URL, it will resort to the Spotify account that are on the players. There is some mystery on how it selects accounts if you have multiple which I haven't investigated, but I have multiple accounts on mine and it still works. They are all in the same family account.

[kshartman]

I don't know if this is good info or not because I am using a typescript rewrite of this repo so I can't check it out. I was just here deciding if I should try and deal with Spotify (I don't personally use it but everyone else in my family does).

[johnnyfleet]

@kshartman - do you have a link to reference for ^^^? I've had only a little time to experiment more but couldn't get the spotify playing on S2.

If there is some knowledge on how to construct the payload now that would be real helpful - and I'd happily give it a try to confirm.

[kshartman]

@kshartman - do you have a link to reference for ^^^? I've had only a little time to experiment more but couldn't get the spotify playing on S2.

If there is some knowledge on how to construct the payload now that would be real helpful - and I'd happily give it a try to confirm.

I just banged it into chatgpt. Here is what it said https://chatgpt.com/share/68630f66-6d30-800e-b976-9ec8183f5035

[johnnyfleet]

Thanks - I'll take a look.

Temporary Workaround

What I did just spot from your message thread is a workaround that I've just confirmed working.

Find the album you want and add it to your sonos favourites. Then list the favourites with

http://[your node-sonos-http-api instance]:5005/[your speaker]/favourites

and then play the favourite

http://[your node-sonos-http-api instance]:5005/[your speaker]/favourite/[favourite name]

I have about 30 albums I have printed, so for now I can add them to favourites and re-code the NFC tag until I figure out how to play the spotify album directly.

Posting this here as a helpful reference for others.

[kshartman]

yeah making it a favorite is the path of least resistance. one thing I found when reimplementing this (here) is spotify playback from non-favorite is really really tricky because of all the undocumented flags, serial number (SN) crap and the metadata. Its much harder in S2 than S1 because there are more restrictions in S2 on browsing services and the like. also the pandora "API" itself is not officially supported so you can get rate limited or blocked if you are not careful with reducing calls with a cache and use backoff when they think you are a bot. good luck.

[johnnyfleet]

I'll probably close this ticket shortly.

The workaround is working well enough for me for now. I'll leave it open for another week then close if no further comments/feedback

[jaredtrent]

I was getting the same 500s using my sonos-vinyl setup. Specifically when sending to my Sonos Amp (apparently Sonos Amps are pickier about this than other models).

From what I can tell this is caused by deprecated new Buffer() calls in older versions of node-sonos-discovery, that can create malformed HTTP requests.

Fortunately this was fixed in the latest soap.js on node-sonos-discovery

You can either download the latest from https://github.com/jishi/node-sonos-discovery/blob/master/lib/helpers/soap.js or update it by running the following:

sed -i 's/new Buffer(0)/Buffer.alloc(0)/g' node_modules/sonos-discovery/lib/helpers/soap.js
sed -i 's/new Buffer(soapBody, '\''utf8'\'')/Buffer.from(soapBody, '\''utf8'\'')/g' node_modules/sonos-discovery/lib/helpers/soap.js

Then restart your service, with something like: sudo systemctl restart node-sonos-http-api

Note this would get overwritten the next time you run npm install, unless you update the package.json to use a newer version that includes the fix (versioning is confusing here. you have to update put v1.8.0 in the node-sonos-discovery package.json then npm install, then restart npm).

[jaredtrent]

There are some other updates to node-sonos-discovery that replace the deprecated buffer call, so updating is a good idea.