mirror of
https://github.com/devgianlu/go-librespot.git
synced 2026-04-26 05:15:49 +03:00
[GH-ISSUE #238] Failed handling dealer request: failed seeking stream: failed reading page: EOF #149
Labels
No labels
bug
enhancement
pull-request
spotify-side
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/go-librespot#149
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @2opremio on GitHub (Oct 27, 2025).
Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/238
This all happens through playback transfer requests using github.com/zmb3/spotify, which used to work just fine (in case it helps). Now it tends to fail with golibrespot has been inactive for a while.
@2opremio commented on GitHub (Nov 4, 2025):
Happened today again.
This always happens when transfering sessions BTW. There may be a problem when setting up the context of a song when it's playback comes from a session transfer.
@devgianlu commented on GitHub (Nov 4, 2025):
The
failed reading page: EOFerror comes from the Vorbis decoder. It seems that a seek is being made to the very end of the track.There should be a log saying
loading ... (paused: ..., position: ...ms)if you increase log level todebug, can you try that and share a log?@2opremio commented on GitHub (Nov 4, 2025):
At trace level:
@2opremio commented on GitHub (Nov 4, 2025):
The late
chunk 3/13printout (and lack of the remaining chunk printous), makes it seems like the piece to seek to may be in chunk yet to be downloaded?Maybe there is a synchronization problem with the downloading goroutines? (I am assuming, since I haven't checked the code)
@devgianlu commented on GitHub (Nov 4, 2025):
The track is ~120 seconds, but the seek is requested at ~34205 seconds (~9.5 hours).
go-librespotwill cap this at the track duration, causing the seek to EOF because it's technically past the end of track.The problem seems that the timestamps coming in are messed up. Since the player is not paused the track position is calculated as
These values are not present in the log, but I assume
spotify_update_timeis the one messed up. I have no idea why that would be since it's all coming from Spotify directly. Is this a Spotify bug?Regarding the fetching of the chunks, it's all fine. The first chunk is loaded to read the Ogg metadata causing the prefetching of the next couple of chunks. In the meantime the seek requests the last chunks and that is fetched too.
@2opremio commented on GitHub (Nov 4, 2025):
Maybe! I am just using github.com/zmb3/spotify for the transfers, and AFAIU I am not sending any explicit seek times.
@2opremio commented on GitHub (Nov 5, 2025):
Also, the player is definitely and 100% not playing at the time I am transferring the context (neither the local one nor golibrespot). Maybe the code is making a wrong assumption there?
Either way, can we at least start the track from the beginning of the week time doesn’t make sense?
@2opremio commented on GitHub (Nov 5, 2025):
I think paused=false only means continue playing not the fact that the player is active or not …
@2opremio commented on GitHub (Nov 6, 2025):
I think I found the root cause. When
paused=false, the code assumes that playback is active and calculates position dynamically, butpaused=falseonly means "continue playing" (intent), not that playback is actually active.During transfers, neither player is actively playing, so the
timestampcan be stale (from a previous session). Calculatingnow - old_timestampgives a huge elapsed time that pushes position way beyond track duration.Looking at
cmd/daemon/state.go,trackPosition()only checksIsPausedand doesn't checkIsPlaying. Theproto/spotify/connectstate/player.protohas bothis_pausedandis_playingfields.The original librespot (Rust) handles this in
connect/src/state.rs:is_playing()which requiresplayer.is_playing && !player.is_pausedbefore calculating dynamic positionupdate_position_in_relation()[0, track_duration]inspirc.rsThe fix should check
IsPlaying(not justIsPaused) before calculating dynamic position, validate timestamp freshness, and fall back to raw position when timestamp is stale or playback isn't active.I have created a PR doing this at #247. I tested it on my system and seems to fix the problem.
@devgianlu commented on GitHub (Nov 6, 2025):
Thanks!