Repository navigation
Description
Hi,
I'm trying to use go-librespot 0.7.1 as a Spotify Connect renderer on Volumio.
The daemon starts correctly and connects to Spotify's Access Point. It successfully completes the key exchange and challenge, and the AP authentication succeeds with my Spotify username.
However, authentication then fails during the login5 step with:
failed running with username and spotify token
error="failed authenticating with login5: failed authenticating with login5: INVALID_CREDENTIALS"
The same result occurs when running go-librespot manually as the volumio user, so this does not appear to be related to systemd.
Environment:
- go-librespot: 0.7.1
- OS: Volumio
- Authentication method: spotify_token
- Zeroconf: enabled
- Zeroconf backend: Avahi
The daemon is started with:
/usr/bin/go-librespot --config_dir /data/go-librespot/
The systemd service itself simply runs the same command as the volumio user.
The configuration file is located at:
/data/go-librespot/config.yml
Relevant configuration:
credentials:
type: spotify_token
spotify_token:
username: ""
access_token: ""
I also checked the go-librespot state:
/data/go-librespot/state.json
It contains:
{"device_id":"","event_manager":null,"credentials":{"username":"","data":null},"last_volume":null}
The log explicitly reports:
"stored credentials not found"
before attempting authentication, so go-librespot appears to be using the credentials from config.yml rather than previously stored credentials.
The connection to Spotify itself works. The logs show:
fetched new accesspoints
fetched new dealers
fetched new spclients
zeroconf server listening on port XXXXX
using avahi-daemon avahi 0.8 for mDNS service registration
connected to ap-gew1.spotify.com:4070
completed keyexchange
completed challenge
authenticated AP username=""
Immediately after that, authentication fails with:
failed running with username and spotify token
error="failed authenticating with login5: failed authenticating with login5: INVALID_CREDENTIALS"
I also tested running it directly without systemd:
sudo -u volumio /usr/bin/go-librespot --config_dir /data/go-librespot/
The result is exactly the same:
INFO running go-librespot 0.7.1
DEBU app state loaded
DEBU stored credentials not found
INFO api server listening on 127.0.0.1:9879
INFO zeroconf server listening on port XXXXX
INFO using avahi-daemon avahi 0.8 for mDNS service registration
DEBU connected to ap-gew1.spotify.com:4070
DEBU completed keyexchange
DEBU completed challenge
INFO authenticated AP username=""
FATA failed running with username and spotify token error="failed authenticating with login5: failed authenticating with login5: INVALID_CREDENTIALS"
I have verified that the Spotify username configured in go-librespot is the account I am trying to authenticate with.
The failure therefore appears to occur specifically during the Spotify login5 authentication using the configured spotify_token, after the connection to the Spotify AP and the initial AP authentication have already succeeded.
Could this be related to a change in Spotify's authentication/login5 protocol, token format, or the way spotify_token credentials are handled in go-librespot 0.7.1?
If there is a newer authentication flow or a different way of obtaining/providing the required credentials, please let me know.
Thanks!
Activity
devgianlu commentedon Aug 12, 2026
It seems like Spotify killed the authentication flow via Login5 when using stored credentials produced by the AP with an access token with a different client ID than the desktop one. Using
type: interactivefor the credentials still works, it's just when the provided access token was obtained with another client ID.This seems a structural and definitive change so I am afraid that this functionality will need removing, but it's worth investigating when I have some time. It might be something stupid like an outdated version string somewhere.
Related thread: https://community.volumio.com/t/new-2023-spotify-plugin/63381/757
albertoo85 commentedon Aug 13, 2026
hi,
Update: I found a working workaround on Volumio.
The original problem with go-librespot 0.7.1 and spotify_token authentication remains: when using the configured spotify_token credentials, go-librespot connects successfully to Spotify, completes the key exchange and challenge, authenticates the Access Point, but then fails at the login5 step with:
failed running with username and spotify token
error="failed authenticating with login5: failed authenticating with login5: INVALID_CREDENTIALS"
I tested this both through the original systemd service and manually as the volumio user, with exactly the same result, so the issue was not related to systemd.
I then tested go-librespot without the spotify_token credentials in config.yml, using only Zeroconf/Spotify Connect authentication.
The working configuration is:
log_level: trace
device_name: "Volumio"
server:
enabled: true
port: 9879
audio_device: "volumio"
device_type: "avr"
bitrate: 320
external_volume: false
normalisation_pregain: 1.0
audio_buffer_time: 500000
audio_period_count: 4
zeroconf_enabled: true
zeroconf_backend: "avahi"
disable_autoplay: true
In other words, I removed the entire credentials section containing:
credentials:
type: spotify_token
spotify_token:
username: "..."
access_token: "..."
With this configuration, go-librespot 0.7.1 starts normally and remains running. The logs show:
running go-librespot 0.7.1
app state loaded
stored credentials not found
api server listening on 127.0.0.1:9879
fetched new accesspoints
fetched new dealers
fetched new spclients
zeroconf server listening on port XXXXX
using avahi-daemon avahi 0.8 for mDNS service registration
new websocket client
Most importantly, Spotify Connect works correctly: the Volumio device appears in Spotify, I can connect to it and play music normally.
I then made this workaround permanent on Volumio by creating a new systemd service which simply runs:
/usr/bin/go-librespot --config_dir /data/go-librespot/
as the volumio user, with:
Restart=always
RestartSec=5
The new service is enabled and currently runs successfully:
go-librespot-fixed.service
Active: active (running)
The relevant process is:
/usr/bin/go-librespot --config_dir /data/go-librespot/
This means the current workaround completely bypasses the failing spotify_token/login5 authentication path and relies on Zeroconf Spotify Connect authentication instead.
This is currently working reliably on my Volumio installation with go-librespot 0.7.1.
So, at least on Volumio, a possible temporary workaround for the Spotify-side authentication problem is to remove the spotify_token credentials and use go-librespot exclusively as a Zeroconf Spotify Connect renderer.
I am posting this update because it may help identify what changed on Spotify's side and/or whether the spotify_token/login5 authentication flow in go-librespot 0.7.1 needs to be updated.
I have not changed the go-librespot binary itself; only the authentication configuration and the way the daemon is started.
The original spotify_token configuration still produces INVALID_CREDENTIALS, while the same go-librespot 0.7.1 binary works correctly through Zeroconf without those credentials.
arjenpdevries commentedon Aug 16, 2026
Let me report that this workaround solves the problem for me:
https://community.volumio.com/t/new-2023-spotify-plugin/63381/800