Daemon IPC (stop, pause, state.get) and MPRIS block while a provider job runs; YouTube provider.tracks ignores limit

Open
  • Is something wrong?
#614 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 6 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
backend, cli

Research direction

Start at the daemon IPC request handling and provider.tracks implementation, then trace how provider work reaches yt-dlp; the issue gives no file paths or test names. Reproduce with the supplied slow provider.search call followed by stop or state.get, and with the YouTube provider.tracks request using limit 200. Done means control, state reads, and MPRIS remain responsive during provider work and YouTube tracks respects limit and offset.

Written by the indexing model from the issue text.

Description

While a slow provider operation runs, the daemon stops answering everything else: stop, pause, state.get, and MPRIS. A YouTube playlist listing can take minutes, and Stop does nothing until it's over.

Version: cliamp v2.3.0 (also v2.0.1), Linux amd64, headless cliamp -d, yt-dlp 2026.08.19.

Repro

Start some audio, then send a slow provider operation in the background and something cheap straight after it:

cliamp remote call provider.search --params '{"provider":"youtube","query":"boards of canada","limit":20}' --wait &
sleep 0.4
cliamp remote call stop --wait        # or: pause, or: cliamp remote state

What happens

Sent 0.4 s into a ~3.5 s provider.search Took effect after
stop (job created_at → started_at) 2.8 s, 3.6 s
pause --wait 3.0 s
cliamp remote state (state.get) 3.4 s, 3.5 s
MPRIS Player.Stop (status became Stopped) 3.2 s

So operations, plain reads and media keys all wait for the provider job. cliamp remote cancel <id> marks the job canceled at once, but the yt-dlp work keeps running and the socket stays blocked just as long.

A few seconds is tolerable for a search. Opening a big YouTube playlist is not. provider.tracks with {"provider":"youtube","playlist":"LL","limit":200} ignores limit: yt-dlp pages on through --playlist-start 101, 201, … 1001 and beyond, roughly 5 s per 100 entries. With a ~2,000-track Liked playlist the daemon was unresponsive for about 3 minutes. Stop, pause and status did nothing in that window, and IPC clients with a read timeout gave up. cliamp then logged a burst of ipc: write response: … i/o timeout / use of closed network connection when it caught up.

Expected

  • Playback control (stop, pause, toggle, volume, …), state.get and MPRIS stay responsive while a provider is listing or searching. Provider I/O would run off the loop that serves the socket.
  • provider.tracks honors limit/offset for the YouTube providers, fetching only the pages it needs.

Found while building a Winamp-style frontend that drives cliamp -d over IPC v2, where the Stop button appeared broken. I'm happy to retest a fix.

Dominant language
Go
Stars
4.4k
Forks
307
Avg merge
4d 18h
Merged PRs (30d)
13

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from bjarneo/cliamp

All issues in bjarneo/cliamp

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.