The playback queue currently lives only on the client. It should be stored server-side so it survives reloads and can be continued from any other device the user is logged in on.
Expected behavior
The queue (tracks, order, current track and playback position) is saved on the server for each user.
Changes to the queue (add, remove, reorder, skip) are synced to the server.
Opening Musify on another device restores the same queue and lets the user resume where they left off.
Ideally, changes propagate in near real time between active sessions (e.g. via WebSocket/SSE), or at least on focus/load.
Considerations
Conflict handling when two devices modify the queue at the same time (e.g. last-write-wins with timestamps).
Throttle/debounce position updates to avoid excessive requests.
## Summary
The playback queue currently lives only on the client. It should be stored server-side so it survives reloads and can be continued from any other device the user is logged in on.
## Expected behavior
- The queue (tracks, order, current track and playback position) is saved on the server for each user.
- Changes to the queue (add, remove, reorder, skip) are synced to the server.
- Opening Musify on another device restores the same queue and lets the user resume where they left off.
- Ideally, changes propagate in near real time between active sessions (e.g. via WebSocket/SSE), or at least on focus/load.
## Considerations
- Conflict handling when two devices modify the queue at the same time (e.g. last-write-wins with timestamps).
- Throttle/debounce position updates to avoid excessive requests.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
The playback queue currently lives only on the client. It should be stored server-side so it survives reloads and can be continued from any other device the user is logged in on.
Expected behavior
Considerations