[GH-ISSUE #288] Seek in long station contexts always times out due to O(n) sequential page fetching #174

New issue

Open

opened 2026-02-28 14:25:59 +03:00 by kerem · 0 comments

kerem commented

2026-02-28 14:25:59 +03:00

Owner

Originally created by @leodurandfr on GitHub (Feb 11, 2026).
Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/288

When transferring playback to go-librespot with a long listening history, TrySeek always times out because it must sequentially fetch every page from 0 to N via linked-list pagination (NextPageUrl).

Example: station with 28,500 tracks requires fetching 570 pages sequentially within the 30-second dealer timeout, which is physically impossible (~57s minimum on typical hardware).

Error log:

level=warning msg="failed seeking to track in context spotify:station:track:..." 
  error="failed fetching tracks for seek: failed moving to next index 28500 (page 570): 
  failed fetching next page: failed requesting page at radio-apollo/v3/tracks/...: 
  spclient request failed: context deadline exceeded"
level=error msg="failed put state after update" error="context deadline exceeded"
level=warning msg="failed handling dealer request" 
  error="failed loading current track (transfer): failed creating stream for spotify:track:...: 
  failed getting track metadata: spclient request failed: context deadline exceeded"

Root cause in code:

Seek() in tracks/tracks.go starts from iterStart() (position -1) and walks forward
ContextResolver.Page() in spclient/context_resolver.go follows NextPageUrl sequentially — no way to jump to page N directly
The 30s dealer timeout (player.go:76) is insufficient for hundreds of pages

Possible fixes:

Skip seek on timeout - if TrySeek fails, play the requested track directly without resolving the full context position, then lazy-load context pages in the background
Limit seek depth - cap the maximum number of pages fetched during seek (e.g., 50 pages) and fall back gracefully
Parallel page prefetching - if page URLs follow a predictable pattern, fetch multiple pages concurrently

Environment: go-librespot v0.6.2, Raspberry Pi 5

Originally created by @leodurandfr on GitHub (Feb 11, 2026). Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/288 When transferring playback to go-librespot with a long listening history, TrySeek always times out because it must sequentially fetch every page from 0 to N via linked-list pagination (NextPageUrl). **Example:** station with 28,500 tracks requires fetching 570 pages sequentially within the 30-second dealer timeout, which is physically impossible (~57s minimum on typical hardware). **Error log:** ``` level=warning msg="failed seeking to track in context spotify:station:track:..." error="failed fetching tracks for seek: failed moving to next index 28500 (page 570): failed fetching next page: failed requesting page at radio-apollo/v3/tracks/...: spclient request failed: context deadline exceeded" level=error msg="failed put state after update" error="context deadline exceeded" level=warning msg="failed handling dealer request" error="failed loading current track (transfer): failed creating stream for spotify:track:...: failed getting track metadata: spclient request failed: context deadline exceeded" ``` **Root cause in code:** - Seek() in tracks/tracks.go starts from iterStart() (position -1) and walks forward - ContextResolver.Page() in spclient/context_resolver.go follows NextPageUrl sequentially — no way to jump to page N directly - The 30s dealer timeout (player.go:76) is insufficient for hundreds of pages **Possible fixes:** 1. Skip seek on timeout - if TrySeek fails, play the requested track directly without resolving the full context position, then lazy-load context pages in the background 2. Limit seek depth - cap the maximum number of pages fetched during seek (e.g., 50 pages) and fall back gracefully 3. Parallel page prefetching - if page URLs follow a predictable pattern, fetch multiple pages concurrently **Environment:** go-librespot v0.6.2, Raspberry Pi 5