mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #1623] Librespot fails to play any tracks #739
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#739
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 (Nov 6, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1623
Description
Looks like Spotify changed something again on their servers and is causing librespot to stop playing tracks. I can successfully connect but tracks do not play. On initial connect there is a log that indicates
setup of state failed: invalid stateand a400 bad requestwith the message that the client specified an invalid argument. Skipping to the next track causes librespot to fail with continuousTrack should be available, but no alternatives foundAppears that Spotify's servers made some breaking changes to their API. Thoughts?
Version
dev, v0.7.0, v0.7.1
How to reproduce
Log
Host (what you are running
librespoton):Additional context
@GabeMillikan commented on GitHub (Nov 6, 2025):
+1 identical issue on both windows and macos, same code was working yesterday
@timglong commented on GitHub (Nov 6, 2025):
I was still using 0.6.0 with apresolve.spotify.com blocked and it broke that as well, in case anyone else has been waiting to update.
@kingosticks commented on GitHub (Nov 6, 2025):
See #1622
@YutongGu commented on GitHub (Nov 7, 2025):
Tested out #1622 and it worked like a charm. Thanks @photovoltex for responding quickly with a PR!
@milnivlek commented on GitHub (Nov 7, 2025):
Yes, the fix works great! Thank you @photovoltex!
@Semmu commented on GitHub (Nov 7, 2025):
Spotify seems to change their backend very frequently, breaking librespot and other projects as a result. I really wonder how they keep all their official clients working and what API those actually use. (I mean the more obscure clients, such as the IKEA Symfonisk speaker or various smart TV apps, etc.)
@miltieIV2 commented on GitHub (Nov 7, 2025):
Can we please get regular releases after break/fix situations like this?
It will help build trust with the project - when things break and the latest is still v0.7.1 from Aug, it breaks down trust.
I know this fix has only been out for 20h, but this comment is more about past break/fix situations...
@timglong commented on GitHub (Nov 7, 2025):
To provide a counterweight to the above, it's incredible to me that this project exists and that a fix (for this issue, and for the previous issue that led to 0.7.0) was in place basically instantaneously. This project has motivated me to add "learn Rust so I can help with librespot at some point" to my to-do list.
@Semmu commented on GitHub (Nov 7, 2025):
Yes, we should be grateful that librespot exists in the first place. (Though if it didn't, I would have stopped giving any money to Spotify a long time ago...)
@roderickvd commented on GitHub (Nov 7, 2025):
Of course this always has to happen when I'm abroad 😏
Let's go through the PRs and will coordinate with @photovoltex and @kingosticks to do a point release coming days.
While we feel the responsibility to the community, remember this is a after-work hobby for all of us.
@naed437 commented on GitHub (Nov 7, 2025):
Any fix for the java version?
@LowerHater commented on GitHub (Nov 7, 2025):
Will add my voice to that Thank Yous. Librespot (incorporated into Raspotify piped to Owntone; allows me to use cheap ancient $10 Airport Expresses to stream multiroom audio to 5 rooms where I have active speakers and/or amps.
@roelandp commented on GitHub (Nov 7, 2025):
Found this thread when debugging Gstreamer for Mopidy, based on libspotify and wanted to chime in to thank the maintainers for doing the hard work in making our lives more fun by having opensource audio enriching our experience on earth. Hope I can pay back soon with a simple party upvote playlist app and opensource that.
@hechtoid commented on GitHub (Nov 7, 2025):
Cheers on the speedy resolution!!
Already streaming again down on Raspbian
@gfro84 commented on GitHub (Nov 7, 2025):
My biggest fear of any open source project that I love getting too popular is that it spoils the fun of it for the author! I'm disappointed Spotify have killed the lossless and I don't know if this new issue is spite on their behalf, but I am very grateful for the years of enjoyment I've had out of librespot for many
@photovoltex commented on GitHub (Nov 7, 2025):
This issue here was bound to happen at some point. We previously just implemented a quick workout and forgot to replace it with the clean solution.
So the lossless part and this topic is probably totally unrelated and just a move on modernising their infrastructure.
@Moltey commented on GitHub (Nov 8, 2025):
Thank you for your great work in immediate resolution of the issue.
The issue is bringing up one question in me, as this was not the first time that spotify is implementing breaking changes in their infrastructure:
Would greatly appreciate if someone could share their insights.
@roderickvd commented on GitHub (Nov 8, 2025):
Most of them seem fine. Then again, they are using some official SDK that was acting different in the first place, or possibly have had fallback mechanism in place. We only try and mimic what we see.
@kingosticks commented on GitHub (Nov 8, 2025):
They are in control of (most of) their changes. They can keep old and new versions going, update client software to new version, yank old version, nobody notices. We use old version until it's suddenly yanked and then we scramble to find and implement the new version, so we notice. There's no way around this when using private, undocumented APIs.
@abemagro commented on GitHub (Nov 8, 2025):
Hello everyone. Having the same problem with spotifyd on raspberry pi. I am a newbie. Do I understand correctly that the solution is to Build spotifyd myself from source with the new librespot?
@paulbastian commented on GitHub (Nov 9, 2025):
Is it possible to do a new release including this fix?
@photovoltex commented on GitHub (Nov 9, 2025):
That's the plan. But as this is just an side project for most maintainers, it can take a bit until the time is found to do the releases. We are working on improving the cycles in which we can do release, but currently it has to wait a bit until the time is found.
If you need the current version ASAP you can always include the repository as git dependency see: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories
@pejobo commented on GitHub (Nov 9, 2025):
@abemagro should be.
I'm not an expert, actually I'm currently struggling with either the rebuild or I'm running into another issue.
@photovoltex maybe you could help?
This is my log after updating (see comment below):
What startles me is that in the log this is still reporting as commit id
c4766ce, which is the last time I updated.I'm using docker cross compile, I even tried with a fresh clone of the repository to ensure that no temporary files were sitting around (I also deleted the entire /tmp/librespot-build directory).
@photovoltex commented on GitHub (Nov 9, 2025):
@abemagro It's not as easy to update something like
spotifyd. But you can probably start with one of these PR's https://github.com/Spotifyd/spotifyd/pull/1371 / https://github.com/Spotifyd/spotifyd/pull/1362 and then change the dependencies from the versioned dependencys to a git dependency. This will probably break some code tho.As for @pejobo, you still seem to use a old version without the fixes see the referenced commit
c4766ce.@pejobo commented on GitHub (Nov 9, 2025):
Thanks for the quick reply @photovoltex - I was assuming the same. During compilation, are there some cache directories used somewhere (besides in the build directory, which I deleted completely)?
@photovoltex commented on GitHub (Nov 9, 2025):
Could you provide the changes you applied to your
Cargo.toml?@pejobo commented on GitHub (Nov 9, 2025):
I've got no changes on Cargo.toml, but I think I found it - the old docker image was still lying around and it seems to have the (old) code baked in - next attempt is currently running.
I will report back - meanwhile many thanks for your support!
UPDATE:
That seems to be the case - at least now I'm sitting on a build failure
UPDATE 2:
Now all works again 🎉 . Build failure was a missing setting in my build script.
@rwjack commented on GitHub (Nov 9, 2025):
Does anyone know how I can build and install the latest Librespot commit on an alpine container?
I currently just install the latest built package as per:
github.com/rwjack/addon-snapserver-spotify@48163102ce/snapserver/Dockerfile (L18)@timglong commented on GitHub (Nov 9, 2025):
Thanks for this @photovoltex ! This gave me the hint I needed to figure out where to look to find the
--gitoption forcargo install.If there are other folks with limited Rust experience trying to figure out how to get the update working, the following worked for me (Raspberry Pi 4B running bookworm, previously followed the instructions to set up Rust and install librespot, etc.):
cargo install --git https://github.com/librespot-org/librespot --branch devIf there's some reason to avoid this approach, please let me know. The only downside I see is that this approach requires a commit, which might add a slight delay if speed is the primary concern (in this case less than 2 days). I suppose there's also a risk because other commits can be pulled in, but my understanding is this can be avoided if desired by using
--revinstead of--branchand specifying the specific commit hash.@pejobo commented on GitHub (Nov 9, 2025):
@timglong even so I screwed it this time it's maybe easier to cross compile with the docker environment, either on another computer (more powerful and therefore faster) or on the Pi itself (less impact on the host system due to additional packages).
See https://github.com/librespot-org/librespot/wiki/Cross-compiling
@abemagro commented on GitHub (Nov 9, 2025):
I actually tried to build spotifyd myself from source with the new librespot but got several errors and while troubleshooting realized that @eladyn already made the change to spotifyd. So I was able to successfully build with the following commit.
github.com/Spotifyd/spotifyd@59482ed710However I still observe similar behaviour
[INFO] active device is <> with session <7e94d084f3e066529569b7862b08fd03>
^[[A[WARN] couldn't load context info because: context is not available. type: Default
[ERROR] Unable to load audio item: Error { kind: NotFound, error: StatusCode(404) }
[ERROR] Skipping to next track, unable to load track <SpotifyId("spotify:episode:3JlhJOvpqIegWT7pOq1dPm")>: ()
[ERROR] could not dispatch player event: Invalid state { context is not available. type: Default }
[WARN] couldn't load context info because: context is not available. type: Default
[ERROR] Track should be available, but no alternatives found.
[WARN] spotify:track:3n3Ppam7vgaVa1iaRUc9Lp is not available
[ERROR] Skipping to next track, unable to load track <SpotifyId("spotify:track:3n3Ppam7vgaVa1iaRUc9Lp")>: ()
[INFO] Not playing next track because there are no more tracks left in queue.
Any idea why it would not work for me? Did it work for others
By the way thanks a lot for your support so far!
@michaelcadilhac commented on GitHub (Nov 10, 2025):
Using master, still no track gets playing:
@roelandp commented on GitHub (Nov 10, 2025):
@michaelcadilhac afaiu dev branch has all the fixes implemented. maybe try that?
@michaelcadilhac commented on GitHub (Nov 10, 2025):
It may, but it does not compile:
This is on Arch Linux using the AUR parameters:
One of the fixes between dev and master fixed it.
@photovoltex commented on GitHub (Nov 10, 2025):
That issue was resolve with
github.com/librespot-org/librespot@56dc25d0fe. Please check if your fork/repository uses the latest git version.@michaelcadilhac commented on GitHub (Nov 10, 2025):
That's on me, you're entirely right.
devand the AUR package work now; sorry for the noise.@Tsjippy commented on GitHub (Nov 16, 2025):
When will this be released?
@poettig commented on GitHub (Nov 16, 2025):
6 days ago
@Tsjippy commented on GitHub (Nov 16, 2025):
Sorry that was a stupid question.
I use Spotifyd any clue how I update librespot while waiting for a new release of apotifyd
@photovoltex commented on GitHub (Nov 16, 2025):
You can see the progress here (https://github.com/Spotifyd/spotifyd/pull/1376) and probably be able to checkout the branch to use it.