[GH-ISSUE #175] Spotify rate limit issue #103

New issue

Open

opened 2026-02-27 19:28:25 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 19:28:25 +03:00

Owner

Originally created by @tobsch on GitHub (Feb 22, 2026).
Original GitHub issue: https://github.com/lox-audioserver/lox-audioserver/issues/175

After getting Spotify authentication to work (thank you @rudyberends), I have a follow up issue with Spotify:
Whenever I enable Spotify Connect centrally, the audioserver spawns one librespot session per zone (11 in my case), all using the same Spotify account. On startup, all 11
sessions try to connect to Spotify's dealer websocket simultaneously, which seems to cause Spotify to rate-limit them with HTTP 429 (Too Many Requests).

After the rate limit, the websocket connections never recover - they enter a loop of "Connection reset by peer" / "Broken pipe" errors, eventually degrading into a permanent "couldn't load context info because: context is not available" state. The zones never properly register as Spotify Connect devices, so playback from the Spotify client doesn't reach the audioserver
(all zones show "stop").

A container restart temporarily fixes it, but the issue recurs because all sessions reconnect at once and trigger the rate limit again.

Relevant log sequence:
starting dealer failed: Invalid state { HTTP error: 429 Too Many Requests }
Websocket connection failed: IO error: Connection reset by peer (os error 104)
couldn't load context info because: context is not available. type: Default

Originally created by @tobsch on GitHub (Feb 22, 2026). Original GitHub issue: https://github.com/lox-audioserver/lox-audioserver/issues/175 After getting Spotify authentication to work (thank you @rudyberends), I have a follow up issue with Spotify: Whenever I enable Spotify Connect centrally, the audioserver spawns one librespot session per zone (11 in my case), all using the same Spotify account. On startup, all 11 sessions try to connect to Spotify's dealer websocket simultaneously, which seems to cause Spotify to rate-limit them with HTTP 429 (Too Many Requests). After the rate limit, the websocket connections never recover - they enter a loop of "Connection reset by peer" / "Broken pipe" errors, eventually degrading into a permanent "couldn't load context info because: context is not available" state. The zones never properly register as Spotify Connect devices, so playback from the Spotify client doesn't reach the audioserver (all zones show "stop"). A container restart temporarily fixes it, but the issue recurs because all sessions reconnect at once and trigger the rate limit again. Relevant log sequence: starting dealer failed: Invalid state { HTTP error: 429 Too Many Requests } Websocket connection failed: IO error: Connection reset by peer (os error 104) couldn't load context info because: context is not available. type: Default

kerem commented

2026-02-27 19:28:26 +03:00

Author

Owner

@rudyberends commented on GitHub (Feb 22, 2026):

I see. I have added a fix that should address the Spotify rate-limit issue.

When Spotify Connect is enabled for many zones, all librespot sessions were starting and reconnecting in sync. That caused simultaneous dealer websocket connections, resulting in HTTP 429 responses and unstable reconnect loops.

The fix introduces two protections:

Staggered startup: Spotify Connect sessions now start per zone with spacing (currently 5 seconds per zone), instead of all at once.
Desynchronized retry backoff: reconnect attempts now use longer backoff plus per-zone spread/jitter, with extra delay when errors indicate rate limiting (429 / “Too Many Requests”).

This should prevent synchronized bursts, reduce rate-limit pressure, and improve recovery after transient failures.

You can use the dev branch for local testing, or If you need a container you can use;
ghcr.io/lox-audioserver/lox-audioserver:testing-20260222102207

Please note that this adds startup delay. For your last zone it will take one minute for spotify connect to startup after you restart the server.

@rudyberends commented on GitHub (Feb 22, 2026): I see. I have added a fix that should address the Spotify rate-limit issue. When Spotify Connect is enabled for many zones, all librespot sessions were starting and reconnecting in sync. That caused simultaneous dealer websocket connections, resulting in HTTP 429 responses and unstable reconnect loops. The fix introduces two protections: - Staggered startup: Spotify Connect sessions now start per zone with spacing (currently 5 seconds per zone), instead of all at once. - Desynchronized retry backoff: reconnect attempts now use longer backoff plus per-zone spread/jitter, with extra delay when errors indicate rate limiting (429 / “Too Many Requests”). This should prevent synchronized bursts, reduce rate-limit pressure, and improve recovery after transient failures. You can use the dev branch for local testing, or If you need a container you can use; `ghcr.io/lox-audioserver/lox-audioserver:testing-20260222102207` Please note that this adds startup delay. For your last zone it will take one minute for spotify connect to startup after you restart the server.