This comes from building my son a Pi-based music player (Pimoroni screen + buttons) that runs go-librespot and starts playback from a Spotify share link. Like any kid, he wants to find that one song on his playlist — either by seeing all the songs at once, or by skipping quickly through them with the next/prev buttons.
Skipping quickly runs into two things:
- Rapid next/prev draws 429s. Every skip loads and starts the track it lands on — track resolution, audio key, stream — with no debounce, even when the next press arrives milliseconds later and throws it all away. Skipping through N tracks costs N audio-key requests, and Spotify starts rate-limiting well before he finds his song. I see this both when controlling go-librespot from the Spotify iOS app and from my own headless scripts.
- There is no metadata for anything but the playing track. /status describes the current track only, and NextTracks in the connect state carries bare URIs — so the screen can’t show which song is about to play until it has actually loaded. That defeats fast skipping: you can’t stop on the right song if you can’t see which song you’re on.
Related: the only way for a client to list a context’s tracks today is the /web-api/ passthrough to the public Web API — which in my experience rate-limits almost everything these days. Meanwhile the daemon’s own logged-in session already fetches this exact metadata for playback, over spclient endpoints that don’t have that problem.
I’ve addressed both in my fork and would like to submit two independent PRs:
• Skip debounce (configurable window, default measured from real Connect traffic, 0 disables): a burst of next/prev presses moves the track pointer immediately but loads only the track the user stops on.
• Opt-in metadata cache (off by default): caches track metadata from the daemon’s own session, exposes next_track in /status, and adds GET /context/tracks to list any playable context — no Web API involved.
Happy to split, reshape or drop parts of either — opening this first to test your appetite for more PRs from me 😃
This comes from building my son a Pi-based music player (Pimoroni screen + buttons) that runs go-librespot and starts playback from a Spotify share link. Like any kid, he wants to find that one song on his playlist — either by seeing all the songs at once, or by skipping quickly through them with the next/prev buttons.
Skipping quickly runs into two things:
Related: the only way for a client to list a context’s tracks today is the /web-api/ passthrough to the public Web API — which in my experience rate-limits almost everything these days. Meanwhile the daemon’s own logged-in session already fetches this exact metadata for playback, over spclient endpoints that don’t have that problem.
I’ve addressed both in my fork and would like to submit two independent PRs:
• Skip debounce (configurable window, default measured from real Connect traffic, 0 disables): a burst of next/prev presses moves the track pointer immediately but loads only the track the user stops on.
• Opt-in metadata cache (off by default): caches track metadata from the daemon’s own session, exposes next_track in /status, and adds GET /context/tracks to list any playable context — no Web API involved.
Happy to split, reshape or drop parts of either — opening this first to test your appetite for more PRs from me 😃