Repository navigation
Conversation
* make SpotifyId::to_base62() infallible
The only error case is a non-utf8 string, which is impossible since we're building it from a fixed alphabet.
This allows removing a bunch of unnecessary error handling branches.
* make {SpotifyId, FileId}::to_base16() infallible too
* fix core unit tests
* changelog entry
…1642) * Update main.rs * i love github file editing * Update main.rs * Update CHANGELOG.md
…#1645) Added a note to check for the latest release before reporting bugs. Although if they don't bother checking for existing issues, there's little chance they'll do this either.
…ibrespot-org#1636) * Document how to create a fat binary for Mac x86_64 and Apple Silicon * Remove the hint about the macOS SDK needed. It's no longer needed.
* fix: credential file shouldn't be world readable * fix whitespace Co-authored-by: Felix Prillwitz <photovoltex@mailbox.org> --------- Co-authored-by: Felix Prillwitz <photovoltex@mailbox.org>
For the dealer connection, only the first address was tried. For example when using a VPN, which doesn't support IPv6, the first address might still be an IPv6 address and thus fail. The IPv4 address later in the list is never tried. This relies on the tokio default to try all resolved addresses and use the first that was successful.
* fix: clippy::redundant_closure_for_method_calls * fixup! fix: clippy::redundant_closure_for_method_calls * use Into::into * use Instant::elapsed * cargo fmt * enable clippy lint * add lints to all packages
* Expose AddToQueue command * Add add_to_queue to Spirc * Change parameter type to SpotifyUri * Add support for other `SpotifyUri` types to `Spirc::add_to_queue` * Remove support for `SpotifyUri::Artist` / `SpotifyUri::Show` In order to reflect what the official apps are offering to the user. * EmitAddedToQueueEvent * Add CHANGELOG entry * Remove Artist/Show from handle_add_to_queue * D'oh 😬
this fixes librespot-core failing to build due to vergen-gitcl by pinning the version of its vergen dependency to 9.0.6, which depends on the same version of vergen-lib as vergen-gitcl (0.1.6)
* Emit `Player::SetQueue` event * Remve AddToQueue, switch to SetQueue * Add CHANGELOG, reformat * Emit `SetQueue` once when a track collection is added * Clarify wording Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Just call `emit_set_queue_event()` instead of duplicating * Use QueueTrack struct instead of `(String, String)` * Make SetQueue an opt-in event Other expensive events might be added to `OptInPlayerEvents` in the future. * Refactor to use `ConnectConfig` for opting in to `SetQueue` events * Use explicit initializer value Co-authored-by: Felix Prillwitz <photovoltex@mailbox.org> * Move variable closer to usage * Fix formatting --------- Co-authored-by: Ralph von der Heyden <> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Felix Prillwitz <photovoltex@mailbox.org>
…tatus (librespot-org#1722) * audio: fall back to next CDN URL on non-2xx fetch response AudioFileStreaming::open() resolves several CDN URLs from storage-resolve and loops over them to find one that streams, but the loop only treats a transport error (the Err arm) as a reason to try the next URL. An HTTP error status such as 500 is a successful response at the transport layer, so the Ok(_) arm matches and the loop breaks on that first URL. The StatusCode::PARTIAL_CONTENT check then runs AFTER the loop and returns an error, so the remaining (working) CDN URLs are never attempted and playback fails (surfacing as "Unable to load encrypted file: FailedPrecondition"). Reproducible against Spotify today: storage-resolve returns multiple CDN URLs where the first host (e.g. audio-fa-del-874.spotifycdn.com) returns 500 while the others (audio-cf.spotifycdn.com, audio-fa.scdn.co, audio4-ak.spotifycdn.com) return 206. Every track fails even though working URLs were provided in the same response. Move the 206 acceptance into the loop: only break when a URL responds with PARTIAL_CONTENT; otherwise log the unexpected status and fall through to the next URL. The post-loop status check is kept as a safety net. Tested against a live Premium account: before, 0 tracks loaded (every track returned 500 on the first URL); after, tracks load by failing over from the 500 edge to a 206 one. * audio: remove now-unreachable 206 PARTIAL_CONTENT check + updated changelog. see librespot-org#1725
* clippy: fix unnecessary_sort_by lint https://rust-lang.github.io/rust-clippy/rust-1.97.0/index.html#unnecessary_sort_by * clippy: fix useless_borrows_in_formatting lint https://rust-lang.github.io/rust-clippy/rust-1.97.0/index.html#useless_borrows_in_formatting
… credentials. (librespot-org#1744) Path to directory of credentials file is an optional argument.
* oauth: Add the device authorization flow Adds DeviceAuthClient to librespot-oauth, alongside the existing authorization code flow, and exposes it as --enable-device-auth. Spotify issues a short code which the user enters at spotify.com/pair. librespot then polls Spotify until the user finishes logging in, with no need for a callback. Spotify's /oauth2/device/authorize endpoint is RFC 8628 compliant, so the oauth2 crate drives it without help. Spotify only enables this flow for some client IDs; see docs/device-authorization.md. * docs: List the other client IDs Spotify enables for the device flow
nos1609
force-pushed
the
fastpotify-0.8-arm64
branch
4 times, most recently
from
September 9, 2026 18:13
16b0f90 to
cad676b
Compare
librespot reports Windows ARM/ARM64 as Windows CE ARM in the Access Point handshake. Report these clients as the Win32 x86_64 desktop platform and CPU family instead, while preserving the existing mappings for other operating systems. Add the corresponding entry to the Unreleased changelog. References librespot-org#1737 and crmne/spotifast#123.
nos1609
force-pushed
the
fastpotify-0.8-arm64
branch
from
September 9, 2026 18:32
cad676b to
cd6f019
Compare
nos1609
marked this pull request as draft
September 9, 2026 19:02
Author
|
Superseded by #5, which contains the same Windows ARM64 fix as a clean one-commit downstream cherry-pick based directly on fastpotify-0.8. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Modern Spotify Access Point rejects the obsolete PLATFORM_WINDOWS_CE_ARM signature and CPU_ARM for Windows with ErrorCode::PremiumAccountRequired. Map Windows aarch64 to PLATFORM_WIN32_X86_64 and CpuFamily::CPU_X86_64, resolving connection rejection on Windows on ARM devices.
References librespot-org#1737 and crmne/spotifast#123.