starred/librespot

Fork 0

mirror of https://github.com/librespot-org/librespot.git synced 2026-04-27 00:05:55 +03:00

[PR #1690] Add session recovery with automatic playback resume #1495

New issue

Open

opened 2026-02-27 20:02:40 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 20:02:40 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/librespot-org/librespot/pull/1690
Author: @Arneball
Created: 2/26/2026
Status: 🔄 Open

Base: dev ← Head: session-fix

📝 Commits (1)

ed7ccba Add session recovery with automatic playback resume

📊 Changes

6 files changed (+81 additions, -27 deletions)

View changed files

📝 connect/src/spirc.rs (+20 -5)
📝 core/src/audio_key.rs (+9 -0)
📝 core/src/session.rs (+6 -6)
📝 examples/play_connect.rs (+12 -2)
📝 playback/src/player.rs (+14 -10)
📝 src/main.rs (+20 -4)

📄 Description

When the TCP connection to Spotify access points drops due to network instability, the keep-alive timeout fires after ~80s and invalidates the session. The old spirc shuts down and a new Session + Spirc is created. However, three things went wrong:

Session ID mismatch: The new Session generated a fresh random UUID, so Spotify could not match it to the previous playback session. The automatic transfer in handle_connection_id_update failed because the cluster session_id did not match the new session_id.
Volume reset: ConnectConfig.initial_volume was set once at startup and reused on every reconnection. The new SpircTask initialized the mixer to this stale value instead of the users current volume, causing a jarring volume jump on reconnect.
Playback not resuming: The transfer state from Spotify always has is_paused=true after a disconnect, since the device went offline. handle_transfer used this to set start_playing=false, so the track loaded paused even though the user was actively listening.

Fixes:

Preserve session_id across reconnections for automatic transfer
Preserve mixer volume on reconnect, only override after first connect
Track user play intent via shared Arc was_playing flag
Add force_play parameter to handle_transfer for reconnection resume
Add shutdown reason strings to session.shutdown for debugging
Fast-fail audio key requests when session is invalid
Use RwLock in player for session hot-swap

Testing librespot session recovery via iptables

1. Find the AP connection

ss -tnp | grep librearmv7 | grep 4070

Example output:

ESTAB 0 0  192.168.0.14:57572  34.158.1.133:4070  users:(("librearmv7",pid=3429,fd=17))

Note the destination IP (34.158.1.133) and source port (57572).

2. Block the connection

sudo iptables -A OUTPUT -d <IP> -p tcp --sport <SPORT> --dport 4070 -j DROP
sudo iptables -A INPUT -s <IP> -p tcp --dport <SPORT> --sport 4070 -j DROP

Using the example values:

sudo iptables -A OUTPUT -d 34.158.1.133 -p tcp --sport 57572 --dport 4070 -j DROP
sudo iptables -A INPUT -s 34.158.1.133 -p tcp --dport 57572 --sport 4070 -j DROP

Blocking the specific source port is important — it kills the existing connection while allowing librespot to establish a new one on a different port.

3. Wait for reconnection

The keep-alive timeout fires after ~80 seconds. After that, the session is invalidated and librespot creates a new session + spirc. The audio buffer may sustain playback for another 1-2 minutes before the reconnection completes.

Monitor with:

tail -f /tmp/librespot.log

Look for:

Shutdown: Invalidating session: keep-alive timeout
Preserved session_id across reconnection
start_playing=true (if music was playing)

4. Clean up iptables rules

sudo iptables -F

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/librespot-org/librespot/pull/1690 **Author:** [@Arneball](https://github.com/Arneball) **Created:** 2/26/2026 **Status:** 🔄 Open **Base:** `dev` ← **Head:** `session-fix` --- ### 📝 Commits (1) - [`ed7ccba`](https://github.com/librespot-org/librespot/commit/ed7ccbad4e3f8b198d038402b6d0b68eca95a3bb) Add session recovery with automatic playback resume ### 📊 Changes **6 files changed** (+81 additions, -27 deletions) <details> <summary>View changed files</summary> 📝 `connect/src/spirc.rs` (+20 -5) 📝 `core/src/audio_key.rs` (+9 -0) 📝 `core/src/session.rs` (+6 -6) 📝 `examples/play_connect.rs` (+12 -2) 📝 `playback/src/player.rs` (+14 -10) 📝 `src/main.rs` (+20 -4) </details> ### 📄 Description When the TCP connection to Spotify access points drops due to network instability, the keep-alive timeout fires after ~80s and invalidates the session. The old spirc shuts down and a new Session + Spirc is created. However, three things went wrong: 1. Session ID mismatch: The new Session generated a fresh random UUID, so Spotify could not match it to the previous playback session. The automatic transfer in handle_connection_id_update failed because the cluster session_id did not match the new session_id. 2. Volume reset: ConnectConfig.initial_volume was set once at startup and reused on every reconnection. The new SpircTask initialized the mixer to this stale value instead of the users current volume, causing a jarring volume jump on reconnect. 3. Playback not resuming: The transfer state from Spotify always has is_paused=true after a disconnect, since the device went offline. handle_transfer used this to set start_playing=false, so the track loaded paused even though the user was actively listening. Fixes: - Preserve session_id across reconnections for automatic transfer - Preserve mixer volume on reconnect, only override after first connect - Track user play intent via shared Arc<AtomicBool> was_playing flag - Add force_play parameter to handle_transfer for reconnection resume - Add shutdown reason strings to session.shutdown for debugging - Fast-fail audio key requests when session is invalid - Use RwLock<Session> in player for session hot-swap # Testing librespot session recovery via iptables ## 1. Find the AP connection ```bash ss -tnp | grep librearmv7 | grep 4070 ``` Example output: ``` ESTAB 0 0 192.168.0.14:57572 34.158.1.133:4070 users:(("librearmv7",pid=3429,fd=17)) ``` Note the **destination IP** (`34.158.1.133`) and **source port** (`57572`). ## 2. Block the connection ```bash sudo iptables -A OUTPUT -d <IP> -p tcp --sport <SPORT> --dport 4070 -j DROP sudo iptables -A INPUT -s <IP> -p tcp --dport <SPORT> --sport 4070 -j DROP ``` Using the example values: ```bash sudo iptables -A OUTPUT -d 34.158.1.133 -p tcp --sport 57572 --dport 4070 -j DROP sudo iptables -A INPUT -s 34.158.1.133 -p tcp --dport 57572 --sport 4070 -j DROP ``` Blocking the specific source port is important — it kills the existing connection while allowing librespot to establish a new one on a different port. ## 3. Wait for reconnection The keep-alive timeout fires after ~80 seconds. After that, the session is invalidated and librespot creates a new session + spirc. The audio buffer may sustain playback for another 1-2 minutes before the reconnection completes. Monitor with: ```bash tail -f /tmp/librespot.log ``` Look for: - `Shutdown: Invalidating session: keep-alive timeout` - `Preserved session_id across reconnection` - `start_playing=true` (if music was playing) ## 4. Clean up iptables rules ```bash sudo iptables -F ``` --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

kerem added the

pull-request

label

2026-02-27 20:02:40 +03:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/librespot#1495

No description provided.

Rows
Columns