Question: Is it intentional that jukebox PLAYLIST_UPDATED message is always sent at the same time as SONG_UPDATED?

[BillTheBeast]

Every time a song in the jukebox playlist ends both the PLAYLIST_UPDATED and SONG_UPDATED are currently getting called.
However since the PLAYLIST_UPDATED also contains the info about the new song, the SONG_UPDATED is effectively redundant and is unnecessary.
This likely happens because the song ending causes server to remove the new song from the queue causing the playlist updated also to be sent even if it technically be unnecessary.
So to fix this one of these messages should stop to be sent in this case.

Additionally the SONG_UPDATED messages only includes the song name and the timestamp when it started, while the one in the playlist message also includes the player who added it and the queue id.
The queue id likely would be smart to add to the SONG_UPDATED message as it would make it easier to match the song to the correct song from the queue. (Mainly relevant if the PLAYLIST_UPDATED isn't sent.)

Also if we keep the SONG_UPDATED does the PLAYLIST_UPDATED need to give us the the current song necessarily?

[tickBit]

It seems that when a tune in the jukebox ends and the next one begins, two things happen:

• The backend updates currentSong and removes the new current song from the queue. That is why both SONG_UPDATED and PLAYLIST_UPDATED are triggered by the same event.

We could use one event as the source of truth. I think the simplest solution is:

PLAYLIST_UPDATED already includes currentSong, so SONG_UPDATED is unnecessary during automatic song transitions and can be omitted.

PLAYLIST_UPDATED represents the whole jukebox state and includes both currentSong and the queue. In this case, when a song ends, only PLAYLIST_UPDATED is sent, and a separate SONG_UPDATED event is not needed.

So the frontend logic could be:

• When PLAYLIST_UPDATED is received, update the entire jukebox state based on it.
• If playlist.currentSong has changed, start/synchronize playback using songId + startedAt.
• If currentSong is null, stop/clear the player.

In this model, PLAYLIST_UPDATED is essentially a state snapshot, so a separate SONG_UPDATED event is not needed.

I can write an issue for this.

[tickBit]

If we choose above approach, we do not need to add the queue id to SONG_UPDATED, because SONG_UPDATED would not be sent during automatic song transitions. The queue id is already available in PLAYLIST_UPDATED.currentSong.id.

If we instead decide to keep SONG_UPDATED as the main song transition event and stop sending PLAYLIST_UPDATED in that case, then yes, adding the queue id to SONG_UPDATED would be useful.

I would still keep currentSong in PLAYLIST_UPDATED, because then the message represents the full jukebox state. That makes frontend handling simpler and allows the client to recover from missed or out-of-order messages more easily.