[PR #449] [MERGED] Add blocking SinkActive|SinkInactive events #930

New issue

Closed

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

kerem commented

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

Owner

📋 Pull Request Information

Original PR: https://github.com/librespot-org/librespot/pull/449
Author: @kaymes
Created: 3/10/2020
Status: ✅ Merged
Merged: 7/24/2020
Merged by: @sashahilton00

Base: dev ← Head: blocking_sink_events

📝 Commits (3)

6f28b04 Emit blocking sink events
667e559 Merge remote-tracking branch 'origin/dev' into blocking_sink_events
d4d5525 address merge conflict

📊 Changes

3 files changed (+88 additions, -16 deletions)

View changed files

📝 playback/src/player.rs (+57 -15)
📝 src/main.rs (+15 -1)
📝 src/player_event_handler.rs (+16 -0)

📄 Description

This is kind of the same feature as PR #448, but in a blocking fashion. I'm putting it up for discussion as an alternative approach.

It addresses the issue mentioned in #406.

If activated, librespot emits events before the sink is opened and after it is closed. The events are blocking in the sense that the player waits for the handler to complete. This allows to write a handler that frees the sink before librespot attempts to open it.

From an API side, this is implemented as a callback. If a callback is registered, the player executes it blockingly.
From a binary side if --emit-sink-events is set, the usual --onevent script is used and librespot waits for the script's completion.

For simplicity, the events after closing are blocking, too. To make them non-blocking would require some more special handling to avoid race conditions if the sink is closed and opened in rapid succession.

The callback (and env variables) of the script convey three states: "running", "closed", "temporarily_closed". The latter is being used if the sink is temporarily closed between tracks while loading the next one. This allows the event handler to ignore such temporary closures.

_{🔄 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/449 **Author:** [@kaymes](https://github.com/kaymes) **Created:** 3/10/2020 **Status:** ✅ Merged **Merged:** 7/24/2020 **Merged by:** [@sashahilton00](https://github.com/sashahilton00) **Base:** `dev` ← **Head:** `blocking_sink_events` --- ### 📝 Commits (3) - [`6f28b04`](https://github.com/librespot-org/librespot/commit/6f28b0486fd3110c504e3b39d3a452b6f54e6dce) Emit blocking sink events - [`667e559`](https://github.com/librespot-org/librespot/commit/667e5593400923f19093e88699845e1b01b4f053) Merge remote-tracking branch 'origin/dev' into blocking_sink_events - [`d4d5525`](https://github.com/librespot-org/librespot/commit/d4d55254b035db3a9374835fbe420d5a2340a2e6) address merge conflict ### 📊 Changes **3 files changed** (+88 additions, -16 deletions) <details> <summary>View changed files</summary> 📝 `playback/src/player.rs` (+57 -15) 📝 `src/main.rs` (+15 -1) 📝 `src/player_event_handler.rs` (+16 -0) </details> ### 📄 Description This is kind of the same feature as PR #448, but in a blocking fashion. I'm putting it up for discussion as an alternative approach. It addresses the issue mentioned in #406. If activated, librespot emits events before the sink is opened and after it is closed. The events are blocking in the sense that the player waits for the handler to complete. This allows to write a handler that frees the sink before librespot attempts to open it. From an API side, this is implemented as a callback. If a callback is registered, the player executes it blockingly. From a binary side if --emit-sink-events is set, the usual --onevent script is used and librespot waits for the script's completion. For simplicity, the events after closing are blocking, too. To make them non-blocking would require some more special handling to avoid race conditions if the sink is closed and opened in rapid succession. The callback (and env variables) of the script convey three states: "running", "closed", "temporarily_closed". The latter is being used if the sink is temporarily closed between tracks while loading the next one. This allows the event handler to ignore such temporary closures. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

kerem

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

closed this issue
added the
pull-request
label

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

No description provided.

Rows
Columns