[GH-ISSUE #583] Re-write orign detection. #347

New issue

Open

opened 2026-02-28 14:32:22 +03:00 by kerem · 0 comments

kerem commented

2026-02-28 14:32:22 +03:00

Owner

Originally created by @SO9010 on GitHub (Jan 30, 2025).
Original GitHub issue: https://github.com/jpochyla/psst/issues/583

Current Functionality

When a song is played, it gets sent to psst_core, which processes and plays the song while stripping out all information except ItemId. This ItemId contains only the type (track, podcast, local file, unknown).

On the GUI side, psst_gui retrieves the ItemId of the currently playing item, compares it to the songs in the playback queue (which is just the playlist the user is playing from), and then checks it against the user-added queue.

The issue arises when identifying the song’s origin correctly. If a song is in both the user-added queue and the playback queue, it incorrectly gets reported as coming from the default playback queue. This means that if you add a song to a playlist from one context and then switch to another context where the same song exists, the system assumes it belongs to the new context. As a result, you can’t click on it to return to the original playlist.

Fixing this would not only resolve these context-switching issues but also make implementing a side-playing bar much easier and address problems with depopulating the queue view.

This issue is referenced in #485 —I’m noting it here in case anyone has ideas on how to tackle it. It seems like it’ll require a pretty significant rewrite of the core.

@jacksongoode any ideas? After this is tackled, finishing the sidebar will be far easier.

Originally created by @SO9010 on GitHub (Jan 30, 2025). Original GitHub issue: https://github.com/jpochyla/psst/issues/583 ## Current Functionality When a song is played, it gets sent to `psst_core`, which processes and plays the song while stripping out all information except `ItemId`. This `ItemId` contains only the type (track, podcast, local file, unknown). On the GUI side, `psst_gui` retrieves the `ItemId` of the currently playing item, compares it to the songs in the playback queue (which is just the playlist the user is playing from), and then checks it against the user-added queue. The issue arises when identifying the song’s origin correctly. If a song is in both the user-added queue and the playback queue, it incorrectly gets reported as coming from the default playback queue. This means that if you add a song to a playlist from one context and then switch to another context where the same song exists, the system assumes it belongs to the new context. As a result, you can’t click on it to return to the original playlist. Fixing this would not only resolve these context-switching issues but also make implementing a side-playing bar much easier and address problems with depopulating the queue view. This issue is referenced in #485 —I’m noting it here in case anyone has ideas on how to tackle it. It seems like it’ll require a pretty significant rewrite of the core. @jacksongoode any ideas? After this is tackled, finishing the sidebar will be far easier.