mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #1527] Getting status code 500s since Ads API sunset #693
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#693
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @YutongGu on GitHub (Aug 6, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1527
Description
Starting yesterday (Aug 5th) librespot stopped allowing tracks to be played. Devices still could connect to the librespot instance but playing any tracks would cause the player to rotate through songs, never actually playing anything. Logs show the following error message:
[2025-08-06T16:43:01Z INFO librespot_core::spclient] Resolved "gew1-spclient.spotify.com:443" as spclient access point [2025-08-06T16:43:02Z INFO librespot_core::spclient] Resolved "gew4-spclient.spotify.com:443" as spclient access point [2025-08-06T16:43:03Z INFO librespot_core::spclient] Resolved "guc3-spclient.spotify.com:443" as spclient access point [2025-08-06T16:43:03Z ERROR librespot_playback::player] Unable to load audio item: Error { kind: Unavailable, error: StatusCode(500) }This also seems to correspond with the sunsetting of the Spotify's V2 Ads API: https://developer.spotify.com/documentation/ads-api.
Version
Dev branch:
be37402How to reproduce
Steps to reproduce the behavior in librespot e.g.
Log
Host (what you are running
librespoton):Additional context
@roqueeee commented on GitHub (Aug 6, 2025):
Same, librespot returns
ERROR librespot_playback::player] Unable to load audio item: Error { kind: Unavailable, error: StatusCode(500) }on any song I try to play. It still worked about 6 hours ago.@smoonlee commented on GitHub (Aug 6, 2025):
Have also had issues with raspotify, and thought it might have been OAuth issues based on the recent UK Age vertification waffle. but this confirms its not. 🫡
@kingosticks commented on GitHub (Aug 6, 2025):
Fairly sure we don't use the ads API directly but in the long-running history of Spotify deprecating things, they always (always) break something else along the way.
@lleheny0 commented on GitHub (Aug 6, 2025):
Same here, 500 error and unable to load any songs. I thought at first that I had hit some kind of rate limit because it happened to coincide with me hitting the skip button a bunch of times. Was working fine a few hours ago.
@Mitschmaster commented on GitHub (Aug 6, 2025):
seems i have the same issue.
@Aeiron2 commented on GitHub (Aug 6, 2025):
librespot.core.ApiClient.StatusCodeException: 500 since yesterday
@dachucky commented on GitHub (Aug 6, 2025):
Also seeing this in the version bundled with Music Assistant (
librespot 0.6.0-dev 7127672 (Built on 2025-02-24, Build ID: KpKsLXNx, Profile: release)), with two different errors:More commonly
or more rarely
@YutongGu commented on GitHub (Aug 6, 2025):
I wonder if this issue from the go-librespot library is the same as what we're experiencing here. If so, it looks like they've already addressed it in a PR.
EDIT: I just tried out their latest release from 2 hours ago and it seems to work well.
@kingosticks commented on GitHub (Aug 6, 2025):
I called it!! Spotify engineering never disappoints.
Yep, good spot, we need to port that fix.
@ayosec commented on GitHub (Aug 6, 2025):
I did a quick patch to apply the fix from https://github.com/devgianlu/go-librespot/issues/189#issuecomment-3160813582. The diff is against the tag
v0.6.0:Songs can be played again, though there is a
ContextError(which I'm not sure it started today):@YutongGu commented on GitHub (Aug 6, 2025):
This worked for me too! I'm also getting the context errors though. Is that cause for any concern?
@b-nobis commented on GitHub (Aug 6, 2025):
Also tested it, but it only works partially. Some songs are played, some not.
ERROR librespot_playback::player] Unable to load encrypted file: Error { kind: Unavailable, error: hyper_util::client::legacy::Error(Connect, Custom { kind: Other, error: ConnectError("dns error", Custom { kind: Uncategorized, error: "failed to lookup address information: Name or service not known" }) }) }@kingosticks commented on GitHub (Aug 6, 2025):
There are currently two known issues, this and Spotify providing bad CDN URLs. The fix at #1524 addresses the latter, ideally you'd want to apply the workaround here on top of #1524.
@b-nobis commented on GitHub (Aug 6, 2025):
With both fixes applied, it works like a charm now. Thank you.
@Diegovsky commented on GitHub (Aug 6, 2025):
@ayosec can you open a PR?
@ayosec commented on GitHub (Aug 7, 2025):
I can send a patch if https://github.com/librespot-org/librespot/issues/1527#issuecomment-3161397815 is the correct solution, though I don't know if the maintainers prefer a better approach (like adding another field to
RequestOptions, instead of hard-coding the strings for the URL).@audas commented on GitHub (Aug 7, 2025):
I am a total noob - so I maybe posting in here wrongly. Sorry.
I have rebuilt from latest dev but am getting "ERROR librespot_playback::player] Track should be available, but no alternatives found."
It then skips to next track and repeats this error. I have authenticated etc.
@keks commented on GitHub (Aug 7, 2025):
@audas Since the fix is not merged yet, the changes are not on dev yet. You are seeing the error message described in this issue.
@roderickvd commented on GitHub (Aug 7, 2025):
Looks good to me.
Though I'm on holiday, I can try and find some time to do a release together with @photovoltex.
@reinob commented on GitHub (Aug 7, 2025):
could I ask you how to apply those two fixes? my git knowledge amounts to using git pull, but I don't know how to merge a specific commit, if that makes sense at all ¯\(ツ)/¯
@kingosticks commented on GitHub (Aug 7, 2025):
If you just want to get it working, grab someone's legit fork with the two fixes already applied. This one from @tdgroot looks fine:
@pienczyk commented on GitHub (Aug 7, 2025):
I used the mentioned fork and branch and I can confirm that it is a working solution.
P.S. If someone wants an image (ALSA BACKEND ONLY) - https://hub.docker.com/repository/docker/pienczyk/dockerized-librespot/general
@inox9 commented on GitHub (Aug 7, 2025):
It worked fine for 1-2 hours.
But now here it goes again:
@vulkoingim commented on GitHub (Aug 7, 2025):
FWIW: after applying https://github.com/librespot-org/librespot/issues/1527#issuecomment-3161397815 and https://github.com/librespot-org/librespot/pull/1524 it worked for a bit, and now it's back at it:
logs
@keks commented on GitHub (Aug 7, 2025):
Looks like go-librespot is also affected https://github.com/devgianlu/go-librespot/issues/189#issuecomment-3164282628
@roderickvd commented on GitHub (Aug 7, 2025):
Well, that saves me from pulling out my laptop now on the camping 😁 I'll be around for review and release when y'all have figured it out.
This could also be a temporary error while Spotify is trying to fix whatever they broke. Wouldn't be the first time either.
@Bobronium commented on GitHub (Aug 7, 2025):
For Raspotify users on Raspberry Pi and other arm64 platforms
You can fix the issue by running this (see the release):
This release uses patch from the https://github.com/librespot-org/librespot/issues/1527#issuecomment-3161397815.
As a bonus, after installation you will be able to control librespot playback via cli
Creds for this to https://github.com/librespot-org/librespot/pull/1341
@blackketter commented on GitHub (Aug 7, 2025):
Worked like a charm, thanks @Bobronium !
@emc02 commented on GitHub (Aug 7, 2025):
is there a chance to get a new release with the fix or should I try the solution above?
@ndesgranges commented on GitHub (Aug 7, 2025):
https://github.com/devgianlu/go-librespot/issues/189 mentions it's working again with the fix.
Spotify devs doing funny things
@ayosec commented on GitHub (Aug 7, 2025):
In https://downdetector.com/status/spotify/ many people are reporting problems with Spotify, so it looks like the problem is not specific to librespot (that chart is usually close to zero, when the problem is specific to librespot).
We should wait a couple of days before submitting a PR. It is possible that we don't need any change at all, if this is a temporary issue in Spotify side.
@bsergei commented on GitHub (Aug 8, 2025):
I am on Moode Audio player. Added to /etc/hosts:
0.0.0.0 apresolve.spotify.comThen I rebooted, and librespot started working properly.
This workaround was also mentioned here (please credit author of this workaround if it helps to you):
https://moodeaudio.org/forum/showthread.php?tid=7915&pid=65696#pid65696
@emc02 commented on GitHub (Aug 8, 2025):
That worked for me too!
@lgidon commented on GitHub (Aug 8, 2025):
As per @bsergei's suggestion, I looked at the workaround one post earlier:
"A temporary fix that seems to be working for me is blocking "apresolve.spotify.com" using hosts file or my DNS server and rebooting Moode Audio player."
I'm not running Moode Audio, but I tried blocking apresolve.spotify.com in PiHole and now it seems to be working.
The logs are showing some warnings though:
@siege801 commented on GitHub (Aug 8, 2025):
Adding my findings - running via Raspotify on 2 RPi 4's.
Initially observing this error through
journalctlfor each attempted track.I added
0.0.0.0 apresolve.spotify.comto/etc/hostsand rebooted, and then instead observed the following throughjournalctlSo I removed the line from
/etc/hostsand tried @Bobronium 's solution posted above (here for reference):This worked for me and both Pi's are working again.
Many thanks to all involved and for these great projects.
@SailingSailing commented on GitHub (Aug 8, 2025):
Adding
0.0.0.0 apresolve.spotify.comto /etc/hosts works for me :)@shaylavi commented on GitHub (Aug 8, 2025):
I rarely find comments on GitHub that applies to me lol thank god this one does! blocking apresolve.spotify.com helped me as well! yaay.. surprisingly, the restart was also a required step!
@parky118 commented on GitHub (Aug 8, 2025):
Yes! It works for me too! Thank you!
@ascomycota commented on GitHub (Aug 8, 2025):
Wow. What a simple solution :) It also works here.
Maybe this specific domain should be checked and skipped for communicating inside the raspotify source in the next release? So we all can remove this dirty hack hosts entry again :)
@michaelcadilhac commented on GitHub (Aug 8, 2025):
Been running https://github.com/tdgroot/librespot.git 20250807_fixes for a day now, flawless. No warnings.
Edit: 48 hours now. No problems.
@salmanmohammadi commented on GitHub (Aug 8, 2025):
Is this straight out of an LLM? I think the previous comments were sufficiently helpful for diagnosing and solving the issue.
@roderickvd commented on GitHub (Aug 9, 2025):
👮 I’ve hidden the long and redundant comment generated by @tyler-morales and his LLM. Please do not spam the repo which such posts. Thanks.
@frodeseverin commented on GitHub (Aug 9, 2025):
Without looking at the code at all one ting comes to mind.
In the situation of receiving a HTTP 500 or similar error from a server like in this situation, it would be prudent to add logic for the librespot client to use one of the known good fallback servers, perhaps even in a round-robin fashion, if needed, and then fail only when the list of known fallback servers is exhausted.
This will obviously mask the presence of the error, so there is also need for some ping-back mechanism to alert the developers of the problem. Needles to say such automated ping-back mechanisms should be on an opt-in and anonymous basis. Perhaps by way of a compile-time parameter or runtime switch.
This approach would make for a more robust client, while enabling the developers to do proactive debugging.
@sbt29 commented on GitHub (Aug 9, 2025):
the 0.0.0.0 apresolve.spotify.com didnt work for me. It creates a new problem where the connection to the speaker / audio device drops as soon as I play a track. I have to then reboot the server to get it back up again. deleting 0.0.0.0 apresolve.spotify.com from etc/hosts reverts it back to the original problem, where the connection to the speaker stays and track's playing but without any sound.
@Enurian commented on GitHub (Aug 9, 2025):
This seems to be connected to user accounts somehow. I was baffled that with my account, my raspotify client has the problem here described, but with my partners account (the accounts are even connected through spotify duo) there was no problem on the exact same playback device. The "good" account needs to initiate the session, then it´s fine.
The hosts edit did not work / lead to the "Unable to load encrypted file" errors already mentioned and maybe related to another problem.
@kingosticks commented on GitHub (Aug 9, 2025):
Is this LLM spam too?
@joostvhts commented on GitHub (Aug 9, 2025):
idk, four paragraphs, not the usual three :p
@martidu4 commented on GitHub (Aug 9, 2025):
Ty man it works for me too.
@frodeseverin commented on GitHub (Aug 9, 2025):
Nope. I am a real human being. Just a humble user of librespot.
Sorry for not contributing directly by writing code.
Anyhow, issuing
worked around the present issue on my Debian system.
No need to restart anything else
@sbt29 commented on GitHub (Aug 9, 2025):
is
llm has better things to than reporting a Spotify connect problem here on github i suppose, but who knows, all sorts of things happen today. For example, I use Audiolinux + Raspotify (instead of Spotify connect)
@Auburok commented on GitHub (Aug 10, 2025):
Worked for me on Raspotify—thankful for a simple workaround. Thanks for sharing.
@davids777 commented on GitHub (Aug 10, 2025):
Unsurprisingly, a host override in unbound dns for apresolve.spotify.com to 0.0.0.0 also resolved the problem as it did with /etc/hosts. This is with Music Assistant as a Home Assistant Add-On behind unbound.
@GlebOlsen commented on GitHub (Aug 10, 2025):
Worked for me!
@KREnZE1 commented on GitHub (Aug 10, 2025):
I think some other factor might be interfering too, because I just added the line to my hosts file and it started working again. There seems to be more to it than we currently see
@kingosticks commented on GitHub (Aug 10, 2025):
Just a reminder, since the pertinent information here is now hidden amongst a load of other replies. You'll need the latest dev code and either the fix at #1528, or whatever temporary hack you've found to block apresolve. If you've gone for the blocking hack, you may find it breaks other things in future, so remind yourselves to remove it once you're running with the actual fix.
@tyler-morales commented on GitHub (Aug 10, 2025):
My hope was to provide an explanation of the steps "I", the human took in trouble shooting and summarize it with an LLM. I see that this approach was not helpful. I wonder if there is a way to succinctly provide accurate, concise, and thorough explanation of what happened, what was tried, the fix, and why it works.
I think that this approach would greatly benefit the community without having to comb through the multiple threads of posts that are either verbose or duplicate.
@michaelcadilhac commented on GitHub (Aug 10, 2025):
OK clanker.
This one still works.
To quote @kingosticks :
@reinob commented on GitHub (Aug 10, 2025):
I can confirm that 20250807_fixes works like a charm!
@Chr1s16 commented on GitHub (Aug 10, 2025):
worked for me for my Raspotify on my Pi4 for on Bookworm with a small change: echo "0.0.0.0 apresolve.spotify.com" | sudo tee -a /etc/hosts
@plummer66 commented on GitHub (Aug 11, 2025):
since I am new to all of this......if there is a fix for this....how do I apply it?
@pedymaster commented on GitHub (Aug 11, 2025):
Just the post above yours is working for me running raspotify on my rpi3 with a slight change:
@willthong commented on GitHub (Aug 11, 2025):
Can confirm that the hack, adding
also worked when doing it network-wide, ie added to the
/etc/hostsof the home server runningdnsmasqwhich handles my network's DNS. Thanks!@audas commented on GitHub (Aug 11, 2025):
Hosts file on linux is /etc/hosts you just need to add the line
0.0.0.0 apresolve.spotify.com
save and restart whatever is using it.
@kingosticks commented on GitHub (Aug 11, 2025):
I think we probably have enough workarounds and confirmation of workarounds now. If you need a workaround, scroll up. Otherwise wait for fix that's coming soon.
@olm52 commented on GitHub (Aug 11, 2025):
Problem compiling:
@kingosticks commented on GitHub (Aug 11, 2025):
That error is not related to this issue. Sounds more like https://bugs.gentoo.org/951740
I was misquoted above. I actually tried to suggest people use whatever features they normally use. But I don't know if that would help in your case.
If you think this is actually a librespot problem, please open a new issue with all the debug info we require to help.
@plummer66 commented on GitHub (Aug 11, 2025):
Yeah tried this. While it does get things working, I am finding that it disconnects quite frequently.
Thanks for the responses to a newb people. Much appreciated.
@kingosticks commented on GitHub (Aug 11, 2025):
The fix was merged. Please undo the hacks and run the latest dev branch code. Detailed instructions at https://github.com/librespot-org/librespot/wiki/Compiling. If you need more help to compile, ask at https://github.com/librespot-org/librespot/discussions
@roderickvd commented on GitHub (Aug 12, 2025):
I've begun with the release process. First step is updating the dependencies. My camping internet is unreliable, so this may take some time. I'll be pushing some incremental directly to
devas I go.Some further challenges are that I:
Here's how you can help:
devbranch for new commits, test them and report back any issues.@foonarf commented on GitHub (Aug 12, 2025):
I built raspotify against librespot dev commit
ba3d501for armhf.Confirmed working without the apresolve.spotify.com DNS override workaround.
Running on Raspbian 11 on a Raspberry Pi 4 Model B Rev 1.4.
@roderickvd commented on GitHub (Aug 13, 2025):
I just pushed a few pretty significant commits. Specific things to test:
Many thanks to those who already made a contribution.
If you find an error, open an issue.
If you find everything is OK, please report it here shortly - just the first user, so we don't spam the thread.
@photovoltex commented on GitHub (Aug 13, 2025):
When compiling with 1.81 we get:
@photovoltex commented on GitHub (Aug 13, 2025):
Runnign with just
cargo run -- -j --cache .cachebreaks:I would like to help fix stuff, but I'm limited to testing only right now.
@pienczyk commented on GitHub (Aug 13, 2025):
I just built the commit
fdd4a16and it works fine for me. My build is for the alsa backend only and I am running it inside a docker container on the Raspberry Pi 4B+.My Dockerfile:
@roderickvd commented on GitHub (Aug 13, 2025):
@photovoltex was able to reproduce and fixed in
1dcd041. I took the liberty to bump MSRV to 1.85 and edition to 2024 as more and more libraries are making the jump.@ColtraneNadler commented on GitHub (Aug 14, 2025):
Was this resolved? I am still receiving the error when trying to do playback
in latest version
@photovoltex commented on GitHub (Aug 14, 2025):
What do you mean by "in latest version". This issue is resolved on the
devbranch, aka the published version is still effected as we didn't release a new version, yet.@ColtraneNadler commented on GitHub (Aug 14, 2025):
got it. my mistake then!
@roderickvd commented on GitHub (Aug 24, 2025):
Released v0.7.0 that fixes this and more: https://github.com/librespot-org/librespot/releases/tag/v0.7.0