[GH-ISSUE #311] Librespot doesn't terminate on Ctrl+C if waiting for read #206

New issue

Closed

opened 2026-02-27 19:29:24 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 19:29:24 +03:00

Owner

Originally created by @kaymes on GitHub (Mar 18, 2019).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/311

When I terminate librespot on the console with Ctrl+C, the program doesn't terminate if the stream reader is waiting for a download. The program just hangs and the only way to terminate it seems to be "kill -KILL".

I think, this always happens if the Ctrl+C is pressed while Read for AudioFileStreaming is blocked by the call to self.shared.cond.wait().

I tried to solve it by using cond.wait_timeout() instead, in the hope, that this would get things unstuck once the set timeout (1 second in my test) is reached, but this doesn't seem to be the case.

The best way to reproduce the issue is by starting playback to a song in the middle (so the code has to do a lengthy seek). While it is seeking, hit Ctrl+C.

Originally created by @kaymes on GitHub (Mar 18, 2019). Original GitHub issue: https://github.com/librespot-org/librespot/issues/311 When I terminate librespot on the console with Ctrl+C, the program doesn't terminate if the stream reader is waiting for a download. The program just hangs and the only way to terminate it seems to be "kill -KILL". I think, this always happens if the Ctrl+C is pressed while Read for AudioFileStreaming is blocked by the call to self.shared.cond.wait(). I tried to solve it by using cond.wait_timeout() instead, in the hope, that this would get things unstuck once the set timeout (1 second in my test) is reached, but this doesn't seem to be the case. The best way to reproduce the issue is by starting playback to a song in the middle (so the code has to do a lengthy seek). While it is seeking, hit Ctrl+C.

kerem

2026-02-27 19:29:24 +03:00

closed this issue
added the
enhancement

wontfix
labels

kerem commented

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

Author

Owner

@roderickvd commented on GitHub (Jan 12, 2022):

While somewhat improved in new_api, it's still the case that a graceful shutdown will await all threads that are fetching chunks. I don't see a way of doing an immediate teardown with an enormous amount of code (either channels to all threads with signalling and detection loops everywhere or perhaps unsafe code). In my mind that's not worth it, so I'm tagging this as won't fix.

@roderickvd commented on GitHub (Jan 12, 2022): While somewhat improved in `new_api`, it's still the case that a graceful shutdown will await all threads that are fetching chunks. I don't see a way of doing an immediate teardown with an enormous amount of code (either channels to all threads with signalling and detection loops everywhere or perhaps unsafe code). In my mind that's not worth it, so I'm tagging this as won't fix.

kerem referenced this issue

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

[PR #206] [MERGED] do not panic on connection reset #835

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#206

No description provided.

Rows
Columns