New 2023 Spotify Plugin

pstimpel · June 11, 2026, 5:54am

Ah, great. Did so

http://logs.volumio.org/volumio/WZWm6rO.html

adam_bernatek · June 11, 2026, 1:33pm

@Wheaten @volumio any update on Spotify Lossless support?

Wheaten · June 11, 2026, 2:55pm

No me, I am only a forum moderator

Is3 · June 27, 2026, 12:33pm

To keep thread active.

I would like to announce that I’m waiting for lossless support!
My Rivo plus is also waiting…

cloudcleaner · June 29, 2026, 1:34pm

Greetings,

Newbie here, just switched from Moode Audio, and I’m quite happy with Volumio so far.
The only issue that I have is that a Spotify Connect stream does not start playing when an Internet Radio stream is already active.

Of course, I did my research on that and found that this is somehow a known issue and “by design” because of the underlying Volumio architecture. It looks like few workarounds were suggested in the past, but some of them apparently only apply to older versions of Volumio (or the Autoplay plugin), and others are convoluted and involve adding own code via the console.

Before I go down this rabbit hole, is there maybe a quick and easy fix for Volumio 4 that I can easily implement, maybe just a setting that I missed or a plgin that I need to install? All I want is that Volumio stops all other input sources when Spotify Connect kicks in to allow it overtaking the audio output.

Sorry, if this is an FAQ and already answered somewhere. If it’s already there then it’s not easy to find

Andreas

Wheaten · June 29, 2026, 2:31pm

Currently not an easy fix.
What does work is:

Stop radio
Clear queue
Start Spotify connect

Josh2000 · June 29, 2026, 6:25pm

hey - is that comfortable to do 3 steps before being able to connect ?

there should be be some kind of listener to do that - most users - also me don’t like that

maybe a plugin? @volumio

best greetings

chrish1984 · July 3, 2026, 5:16pm

http://logs.volumio.org/volumio/fjphRCN.html

spotify connect still not working? any ideas anyone?

Suffocation · August 10, 2026, 2:42pm

I’m having issues with crash loops since this afternoon. Had Grok connect to my Volumio and analyse the situation. More people with similar issues?

Bug: Spotify (spop) crash-loops entire Volumio backend

Environment

Volumio 4.119 (bookworm, armhf), Pi 3 Model B
Node v20.5.1
Plugin spop 4.4.1 (Spotify for Volumio4) — changelog says go-librespot 0.5.3; daemon reports go-librespot 0.7.1
First seen this boot: 2026-08-10 15:50 CEST (no older journal on device)

Summary

When Spotify plugin is enabled, go-librespot-daemon repeatedly dies with Spotify login5 INVALID_CREDENTIALS. Volumio backend treats lost websocket to 127.0.0.1:9879 as FATAL and exits. systemd restarts volumio.service → crash loop (49 restarts in ~45 min).

Disabling spop stops the FATAL restarts (backend stays up) but backend may still probe :9879.

Re-auth / remove+reinstall spop did not stop INVALID_CREDENTIALS. UI can show logged-in while daemon still fails.

Root cause (two layers)

1) Primary: go-librespot auth failure

Daemon briefly binds API on 127.0.0.1:9879, then fatals:

authenticated AP username="11*****52"
fatal: failed running with username and spotify token
  error="failed authenticating with login5: INVALID_CREDENTIALS"

Also seen:

stored credentials not found

state.json credentials empty: "credentials":{"username":"","data":null}

Parallel in volumio/spop:

An error occurred while refreshing Spotify Token Error: Bad Request

spop config still holds access/refresh tokens + credentials_type: spotify_token + user id; tokens appear rejected by Spotify login5 / refresh endpoint.

2) Secondary (severity amplifier): uncaught ECONNREFUSED kills core

When daemon is down, spop reconnect fails and process exits:

WARNING: FATAL ERROR
Error: connect ECONNREFUSED 127.0.0.1:9879
  errno: -111, code: 'ECONNREFUSED', address: '127.0.0.1', port: 9879
volumio.service: Main process exited, code=exited, status=1/FAILURE
Scheduled restart job, restart counter is at N

A plugin/daemon auth failure should not take down the whole Volumio backend.

Timeline (this boot)

Time	Event
15:50:18	volumio.service started
15:55:xx	go-librespot loop: listen → INVALID_CREDENTIALS
15:55:42	Spotify Token refresh: Bad Request
15:56:28	first FATAL ECONNREFUSED :9879
15:56:39	restart counter = 1
…	same pattern every ~30–90s
~16:23	spop disabled → FATAL stops (probes may continue)
~16:28+	re-enable / reinstall → FATAL + INVALID_CREDENTIALS return

Counts (same boot, ~16:36)

FATAL ERROR: 49
volumio NRestarts: 49
ECONNREFUSED 127.0.0.1:9879: 334
go-librespot INVALID_CREDENTIALS: 418

Expected

go-librespot accepts valid OAuth token path used by spop, or fails gracefully with clear UI error.
spop must not raise uncaught FATAL on websocket disconnect — log + mark Spotify unavailable only.
UI “logged in” must match daemon auth success.

Reproduce

Enable Spotify (spop) on Volumio 4.119 / bookworm armhf.
Watch: journalctl -u go-librespot-daemon -f and journalctl -u volumio -f
Observe login5 INVALID_CREDENTIALS → ECONNREFUSED → volumio.service restart loop.

Log commands used

journalctl -u volumio -b 0 -o short-iso | grep -E 'FATAL ERROR|ECONNREFUSED 127.0.0.1:9879|Scheduled restart|Spotify Token'
journalctl -u go-librespot-daemon -b 0 -o short-iso | grep -E 'fatal|INVALID|stored credentials|listening'
systemctl show volumio -p NRestarts

Redacted source snippets

go-librespot (typical cycle):

level=info msg="api server listening on 127.0.0.1:9879"
level=info msg="authenticated AP" username="11*****52"
level=fatal msg="failed running with username and spotify token"
  error="failed authenticating with login5: INVALID_CREDENTIALS"

volumio FATAL:

WARNING: FATAL ERROR
Error: connect ECONNREFUSED 127.0.0.1:9879
  code: 'ECONNREFUSED', address: '127.0.0.1', port: 9879
volumio.service: Main process exited, status=1/FAILURE

Token refresh:

An error occurred while refreshing Spotify Token Error: Bad Request

Suffocation · August 10, 2026, 3:06pm

Grok Fixed it for now, but the details are to complex for me, I’ve asked a summery:

For Volumio devs — why Connect works again

Symptom: spop enabled → go-librespot dies with login5: INVALID_CREDENTIALS after being fed OAuth spotify_token (from UI login / vlmapi refresh). Daemon never stays on :9879 → no Spotify Connect. (Also, uncaught local API errors can FATAL-restart volumio.service.)

Root cause (working theory): Web API access token written by spop into go-librespot config is rejected by login5. Not hardware; not a general Spotify outage (AP connect works).

What we did (workaround, not a product fix):

Disabled spop so it stops rewriting credentials / crashing the backend.
Wrote go-librespot config as credentials.type: zeroconf only (no spotify_token block).
Cleared stored empty/bad token state; started go-librespot-daemon alone.
User plays from iOS Spotify → Connect → “Volumio”.

Result: Daemon stays up (authenticated Login5 via Connect handshake), audio to DAC works.

Proof: Same go-librespot 0.7.1 fails with spotify_token, survives with zeroconf-only.

Ask: Don’t require OAuth access tokens for daemon life; prefer Connect/zeroconf for session auth; fix or drop the spotify_token → login5 path; never let spop local API failures take down core Volumio.

Wheaten · August 10, 2026, 3:10pm

Instead of Gorking around. Did you check the time and date on your device? Sounds more like a date time mismatch, causing authentication to fail?

thomaz120 · August 10, 2026, 4:42pm

Same issue here since this afternoon. Volumio + Spotify plugin (spop 4.4.1, go-librespot 0.7.1) on a Raspberry Pi.

go-librespot-daemon crash-loops with login5 INVALID_CREDENTIALS and stored credentials not found. UI shows the track (cover art, title) but there’s no audio and play doesn’t work. Re-authorizing and removing/reinstalling the plugin didn’t help.

Ruled out a date/time mismatch — my clock is correct and System clock synchronized: yes, so that’s not the cause here.

Looking for a fix or workaround. Will follow this thread.

Suffocation · August 10, 2026, 5:15pm

hahaha, I’m borrowing this term from you Groking around.

vs internet Pi 17:13:17 · HTTP Date 17:13:18 → ~1 second off (fine)

Suffocation · August 10, 2026, 5:16pm

This is what my Grok did. And it works. Maybe until restart.

config.yml — before (broken)

credentials:
type: spotify_token
spotify_token:
username: “xxxxxx”
access_token: “”

config.yml — after (works)

credentials:
type: zeroconf
zeroconf:
persist_credentials: true

Full file now:

log_level: info
device_name: “Volumio”
server:
enabled: true
port: 9879
audio_device: “volumio”
device_type: “speaker”
bitrate: 320
external_volume: true
zeroconf_enabled: true
zeroconf_backend: “avahi”
prefer_firewall_friendly_ports: true
credentials:
type: zeroconf
zeroconf:
persist_credentials: true

Also
┌──────────────────────┬──────────────────┐
│ What │ Change │
├──────────────────────┼──────────────────┤
│ spop plugin │ enabled: false │
├──────────────────────┼──────────────────┤
│ go-librespot service │ enabled + active │
└──────────────────────┴──────────────────┘

Suffocation · August 10, 2026, 5:23pm

Btw I retested the “normal” way and the issue has passed for me.

Result: PASS — normal path works again

thomaz120 · August 10, 2026, 5:36pm

Thanks. I tried the normal path again on my end but no luck yet — daemon stays up now (no more fatal crash loop) but it never logs in. Log just shows:

stored credentials not found
zeroconf server listening ...

No INVALID_CREDENTIALS anymore, but also no login. Config still has type: spotify_token with a username + access_token, but the daemon doesn’t seem to use it — likely the stored access_token is expired and the token refresh keeps failing (same “Bad Request” others reported).

So for me the normal path is still broken. Given it started this afternoon for several of us at once and the token-refresh endpoint is what’s failing, I suspect this is a server-side change/outage on Spotify’s end rather than something local — especially since Spotify is in the middle of phasing out username-based login (deadline Sept 1, 2026). Curious if anyone else’s “normal path” is genuinely working again or if it’s intermittent.

b00h000 · August 11, 2026, 10:12am

I have the same issue as reported above, here is my (GPT generated) bug report:

Title:
Spotify / go-librespot INVALID_CREDENTIALS causes Volumio backend restart loop

Environment:
Raspberry Pi 5
Volumio on current Pi 5 image
go-librespot 0.7.1
Spotify Premium account
Audio output: USB to miniDSP SHD Studio
Touch Display plugin enabled

Problem description:
Volumio worked normally for several weeks. On 2026-08-11 it suddenly entered a repeated backend restart/configuration loop.

In the UI this appears approximately every minute as:

Configuration update
Player restarted successfully

Any active audio playback is interrupted each time.

The actual cause appears to be the Spotify / go-librespot integration.

Observed failure chain:
go-librespot starts normally, connects to Spotify access points, performs the key exchange, authenticates the AP, but then fails during login5 authentication:

go-librespot ... authenticated AP username="..."
go-librespot ... fatal msg="failed running with username and spotify token"
error="failed authenticating with login5: failed authenticating with login5: INVALID_CREDENTIALS"

The go-librespot-daemon.service then exits.

A few seconds later the Volumio backend attempts to retrieve the Spotify volume:

info: Getting Spotify volume
Error: connect ECONNREFUSED 127.0.0.1:9879

This connection failure is treated as a fatal backend error:

volumio.service: Main process exited, code=exited, status=1/FAILURE
volumio.service: Failed with result 'exit-code'

Because volumio.service uses Restart=always, systemd starts the backend again. During startup Volumio starts go-librespot again, which repeats the same failure and eventually crashes the backend again.

Important detail:
Normal Spotify authorization through the Volumio UI succeeds.

The logs show:

Spotify credentials grant success
Spotify Successfully logged in

However, the separate go-librespot authentication still fails with:

INVALID_CREDENTIALS

So the normal Spotify API authentication and the go-librespot / Spotify Connect authentication appear to behave differently.

Troubleshooting performed:

Logged out of Spotify in Volumio and reauthorized the account.
No change.
Stopped go-librespot-daemon.service.
Volumio starts the daemon again during backend startup.
Masked go-librespot-daemon.service.
With go-librespot prevented from running, the Volumio backend remained stable and stopped restarting.
Completely reset the persistent go-librespot state:

/data/go-librespot/

The directory previously contained:

config.yml
lockfile
state.json

It was moved aside and recreated empty.

On the first clean startup, go-librespot correctly reported:

no app state found
stored credentials not found
generated new device id

After Spotify was authorized again, the newly configured daemon still failed immediately with:

failed authenticating with login5: INVALID_CREDENTIALS

Therefore the problem does not appear to be caused by stale/corrupt local go-librespot state.

Reproducibility:
Consistent.

Start Volumio with Spotify enabled.
Volumio starts go-librespot-daemon.
go-librespot connects to Spotify and authenticates the AP.
login5 returns INVALID_CREDENTIALS.
go-librespot exits.
Volumio later requests Spotify volume from 127.0.0.1:9879.
Connection is refused.
Volumio Node backend exits with a fatal error.
systemd restarts Volumio.
The sequence repeats.

Expected behaviour:
There appear to be two separate issues:

go-librespot should successfully use the Spotify credentials/tokens generated by the current Volumio Spotify authorization flow.
Even if go-librespot fails or Spotify authentication is rejected, this should not terminate the entire Volumio backend. A failed Spotify volume request should be handled gracefully and Spotify should simply be marked unavailable.

Actual behaviour:
A go-librespot authentication failure ultimately causes the entire Volumio backend to exit, resulting in repeated player/configuration restarts and interrupted playback of unrelated sources such as Radio Paradise.

Temporary workaround:
Masking go-librespot-daemon.service and disabling Spotify prevents the restart loop:

sudo systemctl stop go-librespot-daemon.service
sudo systemctl mask go-librespot-daemon.service
sudo systemctl restart volumio

With Spotify/go-librespot disabled, volumio.service remains stable and NRestarts no longer increases.

Relevant versions/log information:
go-librespot 0.7.1

Volumio service:

ExecStart=/usr/bin/node /volumio/index.js
Restart=always

The failure was reproduced even after deleting all go-librespot state and performing a fresh Spotify authorization.

I can provide the full journal output if useful.

rkorell · August 11, 2026, 10:14am

Hi @thomaz120, @Suffocation — I dug into this on my own box today (Pi 5, HiFiBerry DAC+ Pro, spop 4.4.1, go-librespot 0.7.1) and I think I can explain both why it broke and why it “self-healed” for one of you but not the other. Short version: you don’t need to wait for a server-side fix. The recovery is fully reproducible on the device.

What’s actually failing

The plugin logs you into Spotify’s Web API (via Volumio’s cloud proxy) and writes that Web-API access token into /data/go-librespot/config.yml as credentials: type: spotify_token. go-librespot then tries to use that token against Spotify’s login5 — and since ~Aug 10, login5 rejects it with INVALID_CREDENTIALS. AP auth succeeds (“authenticated AP”), then login5 kills it → crash-loop → it can take the whole backend down with it. So far, so familiar.

Why it “healed” for Suffocation but not for Thomaz120

It isn’t Spotify healing. Look at cmd/daemon/main.go in go-librespot 0.7.1: withCredentials() checks app.state.Credentials.Data (i.e. state.json) first. If a valid stored credential is present, it authenticates with StoredCredentials and ignores the config token entirely. Only if state.json is empty does it fall back to the (currently rejected) token.

Suffocation had set persist_credentials: true and connected once via Spotify Connect — that persisted a valid, app-issued reusable credential into state.json. After that, even “normal” mode used the stored credential and login5 passed. thomaz120’s log showed stored credentials not found → so it fell back to the broken token → fail. Same root, different state.json.

The recipe (one-time phone connect to seed a credential, then back to normal)

SSH in (volumio/volumio). Edit /data/go-librespot/config.yml so the credentials block reads:

credentials:
  type: zeroconf
  zeroconf:
    persist_credentials: true

(The plugin writes type: zeroconf without persist_credentials, which defaults to false — that’s exactly why a plain Connect never persisted anything.)
2. Restart only the daemon, not the plugin (the plugin would regenerate config.yml and wipe your edit):

sudo systemctl restart go-librespot-daemon

Confirm zeroconf server listening in journalctl -u go-librespot-daemon -f.
3. On your phone, open Spotify → pick the device via Spotify Connect → play a few seconds. Then verify the seed landed:

python3 -c "import json;c=json.load(open('/data/go-librespot/state.json'))['credentials'];print(bool(c['username']), len(c['data']))"

You want True and a non-zero length (~264). Restart the daemon once more and you should see loading previously persisted zeroconf credentials → authenticated Login5 with no phone attached — proof the seed survives restarts.
4. Back in the Volumio UI, do the normal Spotify login again (to restore spotify_token mode + the Web-API token for library browse/search). Do not hit “Logout” — logout() calls deleteCredentialsFile() which unlinks state.json and throws you right back to INVALID_CREDENTIALS. The normal OAuth login does not delete it.

After that: go-librespot runs in spotify_token config mode but keeps authenticating via the stored credential, so native browse/search/play from the Volumio screen works again. Verified end-to-end here today.

caveat:

When Spotify/Volumio fix the token path server-side, you don’t have to undo anything — it’ll simply also work via the token again. This is forward-compatible.

Hope this helps you skip the waiting game. Happy to share full logs if useful.

rkorell · August 11, 2026, 10:23am

@b00h000 — I only spotted your detailed report after I’d posted the recipe above, and I want to address it directly, because it looks like a contradiction but actually confirms the same mechanism.

You moved /data/go-librespot/ aside so state.json was empty, then re-authorized through the Volumio UI and still got INVALID_CREDENTIALS. That’s expected — and it’s exactly why your conclusion “not caused by stale/corrupt local state” is right. The UI authorization is the token path: the plugin writes a Spotify Web-API token into config.yml as type: spotify_token. With an empty state.json, go-librespot has no stored credential to prefer, so it falls straight through to that token — which is the thing login5 is currently rejecting. Clearing state can therefore only ever leave you on the broken path.

The fix in my recipe is the opposite of clearing state: you have to populate state.json with a reusable credential that login5 still accepts. Right now the only source of such a credential is a live Spotify Connect (zeroconf) session with persist_credentials: true — not the Web-API token. In cmd/daemon/main.go (go-librespot 0.7.1), withCredentials() checks app.state.Credentials.Data first and uses it via StoredCredentials, ignoring the config token entirely; it only falls back to the token when that data is empty.

I verified both outcomes on my own box today:

token path (empty state) → failed authenticating with login5: INVALID_CREDENTIALS
Connect-seeded stored credential → authenticated Login5, and it survives a daemon restart with no phone attached:

loading previously persisted zeroconf credentials  username="..."
authenticated AP                                   username="..."
authenticated Login5                               username="..."

So the credential material from a Connect handshake and from the Web-API token are simply different, and only the former is passing login5 at the moment. The full step-by-step (seed via zeroconf + persist_credentials: true, one phone connect, then switch back to normal mode without hitting Logout) is in my post just above this posting.

One more thing: your mask go-librespot-daemon.service workaround is the right call if you only want the backend to stop crash-looping — that’s the clean “disable Spotify entirely” path. The recipe above is for the other goal, getting Spotify itself back without waiting on a server-side fix. And you’re spot-on that the second bug here is the backend treating a go-librespot ECONNREFUSED as fatal — a failed Spotify volume request really shouldn’t take down the whole Node backend and interrupt unrelated sources like Radio Stations. That part is worth a separate issue against the plugin.

b00h000 · August 11, 2026, 10:36am

@rkorell, I can confirm the suggested workaround (using zeroconf) works. This is the summary of my troubleshooting tread with GPT, on implementing the workaround:

Workaround confirmed

I was hitting the same go-librespot issue where Volumio kept restarting because go-librespot failed with:

failed authenticating with login5: INVALID_CREDENTIALS

The Volumio backend then tried to query Spotify volume on 127.0.0.1:9879, got ECONNREFUSED, and crashed/restarted.

What fixed it for me was switching go-librespot from spotify_token authentication to Zeroconf.

My working /data/go-librespot/config.yml credentials section is:

credentials:
  type: zeroconf
  zeroconf:
    persist_credentials: true

The important part was the order of operations:

Log out of Spotify in Volumio.
Stop Volumio and go-librespot.
Edit /data/go-librespot/config.yml and replace the spotify_token credentials block with the Zeroconf block above.
Start go-librespot-daemon.
Connect to the Volumio device from the Spotify app using Spotify Connect.
Start Volumio again.

If you stay logged into Spotify through the Volumio UI, Volumio appears to regenerate config.yml and overwrite the Zeroconf configuration with a spotify_token block again.

Since making this change, go-librespot stays active and the Volumio backend no longer enters the restart/configuration loop.

So the underlying issue seems to be the Spotify token configuration generated by Volumio for go-librespot, while Zeroconf authentication works correctly.