You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Current Functionality
When a song is played, it gets sent to
psst_core
, which processes and plays the song while stripping out all information exceptItemId
. ThisItemId
contains only the type (track, podcast, local file, unknown).On the GUI side,
psst_gui
retrieves theItemId
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.
The text was updated successfully, but these errors were encountered: