fondberg
Error ServerTime - Unable to retrieve devices from Spotify when trying to play media
[!WARNING] Spotcast V4 is now completely broken due to changes in the available services from the web browser. Spotify, made the decision to remove the ability to use chromecast devices from web browsers, which was a requirements for spotcast to work.
We have worked on a solution, but the solution requires massive changes in the way Spotcast works. You can try this new version by trying the alpha version. The documentation to setup the new alpha version is here.
(edited) to provide more detail instead of just a copy of the sub-issue)
TL;DR Spotcast is broken, there are no way to fix the solution at the moment. A refactor of the private API side is required
Spotify recently made a change to the web browser, removing the listing of chromecast devices from the web browser.
This fully breaks Spotcast at the moment. Although I am looking into other solution, mostly around spotify desktop app credentials, I am currently unable to confirm if Spotcast will work again.
Bringing this comment over from 542 as this is specific to casting via Google.
Same issue here this morning. I hear Google's connection sound indicating the speaker(s) were ready to receive something. Our Nest Hub screen goes dark like it's about to open Spotify, but then it times out and returns to the previous screen.
spotipy.exceptions.SpotifyException: http status: 404, code:-1 - https://api.spotify.com/v1/me/player/play?device_id=b55ed25715adb930d8f981ecd2bfae62:
Not found., reason: None
I'm on Spotcast v4.0.1, and it worked yesterday.
Experiencing the same issue here when trying to play to Chromecast device.
Spotcast version: 4.0.1
Working fine yesterday but today is completely non functional.
Same problem her. Get the following message: "https://api.spotify.com/v1/me/player/play?device_id=("device id number"): Not found., reason: None ". Checked the device id numbers and they were correct
The issue is global, no need to report that you have the same problem. This is affecting everyone. Lets keep the ticket log for working on the issue.
In regards to SpotifyPlus, the issue comes into play when I try to use the token generated from the Spotify Web Player Cookie credentials process (e.g. SP_DC, SP_KEY). That will cause the transfer playback endpoint to fail with the 404 Not Found error.
If I use the token generated from the Client Application (using client id / secret), the transfer playback works as expected, but cannot awaken idle Chromecast devices.
That tells me that Spotify added some sort of logic to their Spotify Web API to detect the token difference, and disable the functionality. They must have just installed it yesterday for the Transfer Playback endpoint. I believe they installed it last week for the Track Recommendations endpoint, as it started exhibiting the same failure behavior last week.
I don't see a way around this, but thought I would pass my findings along to you if they help.
UPDATE - Forgot to note, that the changes they implemented also affected Sonos devices. Prior to yesterday, playback would transfer to the Sonos device when the Transfer Playback endpoint was called. I now have to issue a SoCo API play call to get the device to transfer play to the Sonos.
My Bose SoundTouch and Amazon Echo devices were not affected.
I really hope their is a way around some of their changes otherwise it's looking like it might be dead in the water for a lot of use cases sadly :(
Making me begin to question my Spotify Premium account.
While I do hate telling people to move from a project that involved a lot of blood, sweat, and tears in it's development, considering this project is broken in it's current state, there's an officially-supported HA add-on Music Assistant. I just set this up and was able to successfully cast to my Google Cast devices using automations. For now, I think this may be the way to go for us. You can get started in HA by going to Settings > Add-Ons > Add-On Store > Scroll down to Music Assistant Server, and install it. The website has a lot more documentation on how to achieve casting via automations, etc. I'd also recommend seeing the website on how to set up Spotify in Music Assistant.
EDIT: My intention for this suggestion is merely to be a temporary band-aid for getting automations working again for us. This is not a suggestion to say, "hey, let's abandon this project altogether," or "hey, this other project is superior to this one."
Yes, I agree Music Assistant has it's downfalls compared to what Spotcast has had to offer, but it gets me by for now until the devs here can find a workaround to get Spotcast working again.
I'm a dev myself, and I get it. When you're utilizing APIs you don't have control over, and they suddenly change without documentation, it brings about a time of uncertainty.
That said, I sincerely thank @fondberg, @fcusson, and the other contributors to this project for all of their hard work. I've used this project for years, and if and when this project gets back up on it's feet, I'll be immediately switching back to it. ❤️
I've been a fan of this component for a long time, I just wish it was more stable - it's stopped working a few times over the past few months - I've taken @CU-Jon 's suggetion and installed Music Assistant, a little reluctantly, but it's gotten my automations working again, and for that I'm grateful. Is there no way to get SpotCast to stop using the cookie approach? seems to be the main reason the integration stops working - other integrations don't seem to use this, and appear to be more stable overall
@madAndroid
Is there no way to get SpotCast to stop using the cookie approach? seems to be the main reason the integration stops working - other integrations don't seem to use this, and appear to be more stable overall
this was documented here
TL;DR: Spotify doesn't provide the scope to be able to run the addUser action that would enable to link a specific chromecast device to a specific spotify account. They reserve that scope to there application (mobile, desktop, or web) only. Meaning we can't register the spotify app on a chromecast device wth the proper account linked without it.
Now the new change makes it that web players are no longer able to connect to other devices anymore. This is (in my opinion) an anti consumer practice that removes a fairly useful functionality to the end user in retaliation to developers wanting to be able to achieve functionalities that Spotify believe they and they alone should be able to do.
To go with @CU-Jon comments, since MusicAssistant enabled multi-accounts for Spotify, I made the move personally to it for most of my automation, but still wanted to keep the project afloat for others that rely on it.
For the sake of completeness, I think it is important to note that Spotcast and Music Assistant, although at first glance, may look like they achieve the same thing, they achieve them in very different and drastic way.
Spotcast doesn't act as a middle-man for the spotify protocol, all it does is provide a set of sensors and actions to interact with spotify, but after the initial hand-shake between a chromecast device and spotify, Spotcast hands-off the rest to the respective platform.
Music Assistant on the other hand is a full media streaming server and acts as a middle-man for everything, meaning it request the media stream from a service to itself and then redirects the media stream to any of its compatible connect speakers.
The advantage of Music Assistant's approach is that it doesn't care about making system compatible to each other, it handles everything as a full middle-man for the media stream. This means that you need an additional server service, allocated ports and allocated resources (ram + cpu cycle) continuously to make it work. Spotcast, on the other hand, is just a series of scripts and applications to handle the handshake and then done, which is much leaner for resource limited servers like a raspberry pi per example where there's a tangible limit to the number of add-ons you can have before it start to be sluggish (again, not my case, my servers have ample rooms for expansion).
One issue I saw with Music Assistant is that it doesn't register as media being played for Spotify, making it not functional with the official Spotify integration since Spotify seems to be unaware that media is being played by the account (at least in my experience), this makes it hard to interact with the media playback with any other means than music assistant, which is not a great user experience compared to the Spotify app when wanting to interact with music discovery, transferring playback or just media control from the phone. That would be an area of great improvement for the UX if music assistant could have a "Your own personal music streaming service" with flagship app and a good recommendation engine, but I don't know how much that is there goal.
Oof... enough with the long monologue. In the end, I would obviously recommend to anyone that can, to at least try Music Assistant and see if it can fit there workflow. For the rest that either can't get it to work the way they want or need specific functionality from Spotcast, I will still work on it and try to find ways to fix the current issue. I am exploring shifting the current cookie based login we are using to use the desktop application credentials instead. I don't know how feasible that is, but still worth exploring. I'll keep this thread updated if I can find anything.
Thank you for the very detailed response, I appreciate it! I've had the same experience with Music Assistant today - that it doesn't appear to be functional via the offical Spotify integration in HA .. and that has some annoyances, but at least my automations work :)
I am exploring shifting the current cookie based login we are using to use the desktop application credentials instead. I don't know how feasible that is, but still worth exploring. I'll keep this thread updated if I can find anything.
This sounds like a good idea, but I don't know enough about the app or process to know whether it would work in the long run - perhaps it would be a more stable approach, and not subject to the whims of the Spotify devs.
This sounds like a good idea, but I don't know enough about the app or process to know whether it would work in the long run - perhaps it would be a more stable approach, and not subject to the whims of the Spotify devs.
The advantages with a desktop app is that they need to account for older version fro people who didn't update the app yet and forcing an update is not always a great user experience, unless they have to implement a big security patch, so it should be more reliable. I'll have to do some packet capture during the weekend, I'll get an idea if I'm able to retrieve any types of credentials used by the application, but since they control the ins and outs of the server and the client, they could be using a public/private key pair and use it to decrypt the authentication details. If that's the case, there isn't much we will be able to do get new credentials.
One issue I saw with Music Assistant is that it doesn't register as media being played for Spotify, making it not functional with the official Spotify integration
This is the show-stopper for me with Music Assistant.
Spotcast allowed me to get music started easily, then I can control from any other surface (phone app, google devices, etc.).
The issue i had with MA is that my speakers and HASS are on different VLANs.
On Sat, May 10, 2025, 2:11 AM Geoff @.***> wrote:
geoffoxholm left a comment (fondberg/spotcast#543) https://github.com/fondberg/spotcast/issues/543#issuecomment-2867520249
One issue I saw with Music Assistant is that it doesn't register as media being played for Spotify, making it not functional with the official Spotify integration
This is the show-stopper for me with Music Assistant.
Spotcast allowed me to get music started easily, then I can control from any other surface (phone app, google devices, etc.).
— Reply to this email directly, view it on GitHub https://github.com/fondberg/spotcast/issues/543#issuecomment-2867520249, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACGD6KSQ3D7FFPQ4K2AIBGT25TVSXAVCNFSM6AAAAAB4ULED3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNRXGUZDAMRUHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
There is another limitation in music assistant that limits its use for Spotify Family subscribers. Music Assistant is multi account, but not multi user. Meaning you can add all family members in the Music Assistant server. But you cannot have active music listening on separate devices from separate users at the same time. This would require multiple instances of Music Assistant server. Creating a spaghetti mess in the HA configuration and wasted resources.
Absolutely agree with everything that's been said here. Music assistant completely misses the point with Spotify, whereas Spotcast was spot on.
When we have something automated and working so well, and then something related to online services stops working, it really shows how much we're stuck in loops with those same online services.
I absolutely despise Spotify, but I have not yet found a way to replace the radio feature, and a way to actually download music, hell I'll even pay for it, just to have it sorted LOCALLY!
Music assistant kind of tries to do this, but I don't see it being there yet, the UI being a major blocker. Having the whole thing on a webpage really sucks for phones, instead of it being a native app.
And yes, as for downloading music, it would likely be easy with Lidarr, but most of the stuff I listen to is just ambient meditation music, which is nowhere to be found on youtube or pretty much anywhere else on the web.
Spotify is a fucking monopoly and we're too busy licking the slop off their shitty API, while paying for it as well, just to be able to enjoy one of the greatest and simplest wonders of mankind, music.
What we really need is a decentralized music platform, with means of supporting artists we listen to, and a way to download that same music locally for local playback, obviously with no "intentional and unauthorized redistribution".
Absolutely agree with everything that's been said here. Music assistant completely misses the point with Spotify, whereas Spotcast was spot on.
When we have something automated and working so well, and then something related to online services stops working, it really shows how much we're stuck in loops with those same online services.
I absolutely despise Spotify, but I have not yet found a way to replace the radio feature, and a way to actually download music, hell I'll even pay for it, just to have it sorted LOCALLY!
Music assistant kind of tries to do this, but I don't see it being there yet, the UI being a major blocker. Having the whole thing on a webpage really sucks for phones, instead of it being a native app.
And yes, as for downloading music, it would likely be easy with Lidarr, but most of the stuff I listen to is just ambient meditation music, which is nowhere to be found on youtube or pretty much anywhere else on the web.
Spotify is a fucking monopoly and we're too busy licking the slop off their shitty API, while paying for it as well, just to be able to enjoy one of the greatest and simplest wonders of mankind, music.
What we really need is a decentralized music platform, with means of supporting artists we listen to, and a way to download that same music locally for local playback, obviously with no "intentional and unauthorized redistribution".
Completely agree.
That being said, Playlist DL comes to play. It is a self-hosted web application for downloading songs, albums, or playlists from Spotify and YouTube as MP3 files.
Then you can import it to Plex or Home Assistant, and with the help of Music Assistant, you can go around Spotify completely.
Have a look at the project here
Hope that helps.
Well well well, excellent. That solves 50% of the problem.
Now we'd just need a pretty UI to control centralized music playback, and MA is the closest in getting there.
Once we have both of those checked, I hope that's when both listeners and artists start using less and less Spotify services.
Sorry guys, but this support thread is NOT the place to pimp / promote your products in the middle of a crisis. I say this as not the owner of Spotcast, but as owner / maintainer of a product in the same boat. Let's keep this thread on point with possible solutions to the Spotcast problem please. @fcusson Please correct me if I'm out of line here. Thanks!
Okay Mr. backseat moderator, even though we all love Spotcast here and appreciate what the devs are doing, this is an attempt to solve a global problem we're all engulfed in. Might be a good idea you take off your horse blinkers and get up to speed with what is happening around you.
@rwjack I'm not only up to speed, but have skin in the game with my SpotifyPlus integration - experiencing the same issue as Spotcast for Google Cast devices. And with that said, I will take the high road on this one - enough has been said to make my point.
Exactly what I'm talking about! Nobody here wants another outage like this, and the thing is, none of us could have done anything to prevent such a scenario from occurring.
Why, you might ask?
Because of the Spotify monopoly. They got us all reeled in, and if their service stops working, we're all out of music. Kind of a scary situation, wouldn't you agree? That's what I was referring you open your eyes to.
Just posting here to voice my support, thanks for all the team's hard work on this integration, I didn't realize how crucial it really was to my day-to-day.
Now that spotify has introduced the breaking change, I will be opening a support case citing this issue and mentioning that I'm considering cancelling my Premium over this. A little communication goes a long way, and Spotify PM(s) have clearly failed their customer base on a pretty massive scale here.
Here's some copy/pasta and a link to voice your dissatisfaction with Spotify's breaking changes and lack of communication about them
Hiya, just posting a message here, no response is really necessary from support. If dev/eng wants to reach out, that'd be nice. Spotify recently introduced a change to it's API breaking Spotcast, a well-known add-on for HomeAssistant. I personally use Spotcast throughout my day to integrate Spotify into my daily routines. I have been a Premium customer for probably 3-4 years at this point, and upgraded to Family to share this service with my loved ones. I am now considering cutting ties with my subscription and porting to a competitor once I've been able to explore options that integrate with HA. I'm writing today to voice my displeasure with the service and overall shock at the lack of communication by Spotify's engineering team regarding these breaking changes. I encourage you to revert the breaking changes and face your community here, communicate with us so we may all continue to enjoy the service. Thank you,
You can read more about the issue here: https://github.com/fondberg/spotcast/issues/543
Use Spotcast to stream my playlists to different Google speakers. Worked perfectly until a few days ago as others noticed.
Also a big fan of Music Assistant. Also use this for my NAS local playlists and digital radio. Never got it to work with Spotify.
Hopefully the devs get this back up and running. Patience.
It looks like spotify is becoming less and less (premium)-customer friendly. Soon they will come up with a paid API like Tesla (just being sarcastic here). Thanks to the spotcast devs for their efforts
It's disappointing that Spotify has changed the rules again. Spotcast is such a great product when it's allowed to work. I've tried music assistant but find it too clunky so really hope that a long term solution can be found so we can all keep using this great product. I'd like to say a massive thanks to all that have done development work on spotcast over its life. 👍❤️
@fcusson I made some progress with the SpotifyPlus integration on getting Chromecast devices to re-activate for Spotify Premium-level accounts ...
Instead of passing the token that was generated from the SP_DC / SP_KEY credentials, pass it a token that has been previously OAuth'ed to the Spotify Desktop Player client id using a streaming scope. You have to cache the token, and update the cache when the token is refreshed. That will activate Spotify Cast App, which then makes the device available in the Spotify Web API device list. You can then call the Spotify Web API transfer playback endpoint, using the users' HA Spotify Developer App token to transfer playback to the Cast device.
Note that the above will not work for Spotify FREE-level membership, as the transfer playback endpoint fails (401-Premium required error).
I use the AuthTokenGenerator.py program that I wrote to create the Spotify Desktop Player OAuth token. The user has to execute the script on their computer; it drives the user to the Spotify OAuth site for approval, then stores the resulting OAuth token to disk. They then have to copy the OAuth token to a token cache file on their HA system for the integration to access / update on token refresh. I wish that part were a little easier ... I could probably do something within HA by creating a separate Spotify Developer App for the Desktop Player token, but have not looked into it. I used existing logic in my integration to accommodate it, since I already the process in place for reactivation of Sonos devices. In fact, I'm using the same access token for Cast activation that I use for Sonos re-activation.
UPDATE - You can use the Spotify Desktop Player Authentication Configuration guide to setup / execute the AuthTokenGenerator python script.
Anyway ... hope it helps with the Spotcast issue.
A different endpoint, but I started getting issues with the search endpoint around the same time: https://github.com/nukeop/nuclear/issues/1799
@thlucas1 I looked into implementing the oauth 2 with pcke directly in home assistant but sadly the redirect url will not work (kind of obvious but still wanted to try) , we won't be able to have a full gui implementation since we can't redirect to my.home-assistant.io.
The script to retrieve a refresh token is currently the best path to a working solution.
@fcusson Do you remember the details of why you can't redirect to https://my.home-assistant.io?
I know I had to modify my SpotifyWebApiPython package to allow the HA OAuth2Session to be used as the session for calls made to the Spotify Web API. That was the hard part for me; I never had issues redirecting to https://my.home-assistant.io, as that is taken care of by Home Assistant itself. You do have to override some methods to point it to the Spotify authorization server, as well as handle refreshing the token, updating the OAuth config, and using the HA OAuth2Session on the calls made to the Spotify Web API.
It definitely wasn't easy, but I was able to make it work in the end. Now if Spotify would just stop breaking things!!! lol
@thlucas1 the redirect url must be part of the allowed redirect url list from the spotify oauth app.
Since the oauth application for the desktop app expects the redirect url to go back to the desktop app, only localhost must be allowed from spotify's own oauth application. That would make sense, their is no point for them to had my.home-assistant.io as part of the white listed redirects.
Otherwise, if I use my custom dev app it works like a charm using home assistant oauth handler, but I'm not allowed to request the streaming scope