Shuffle tracks in place

[photovoltex]

Follow up on #1356 (comment)

• removes duplication of context tracks when shuffling
• shuffle by a given seed, by that we can restore the shuffle state after a spontaneously disconnect

With the updated protobuf definitions, there is technically a given seed from the side of spotify when transfering playback. The given seed seems to be a hex value which we can convert into a u64 (which we currently use as seed value). But the shuffled queue isn't even similar to what spotify shuffles (which makes sense as they use a more preference base algorithm with less randomness). So when transferring we reshuffle unless we have a previous shuffle seed in the context metadata.

Copilot reviewed 5 out of 11 changed files in this pull request and generated no comments.

Files not reviewed (6)

• connect/src/lib.rs: Evaluated as low risk
• connect/src/state.rs: Evaluated as low risk
• connect/src/state/context.rs: Evaluated as low risk
• connect/src/context_resolver.rs: Evaluated as low risk
• connect/src/state/tracks.rs: Evaluated as low risk
• connect/src/state/options.rs: Evaluated as low risk

Comments suppressed due to low confidence (1)

connect/src/shuffle_vec.rs:92

• The unshuffle method might not correctly restore the original order if the vector was shuffled multiple times with different seeds. Consider storing the original order or using a different approach to unshuffle.

let n = indices[self.vec.len() - i - 1];

[photovoltex]

Huh, fair point from copilot that multiple shuffles might create weird states. Will try to appoint that possible issue. I don't think it can occur in the current state, but it might still make sense to prevent possible multiple unshuffle or shuffle calls.

[roderickvd]

🎉 for AI

[photovoltex]

Welp never mind. I had hoped copilot found something that isn't there... But the cases are already covered.

When you unshuffle it only does so, when it was shuffled to begin with. And we only shuffle on the base content. So when it's already shuffled we unshuffle before we shuffle.

[roderickvd]

Cool!

Question: when you shuffle or unshuffle, while you already have the next track preloaded for gapless playback, how do you manage that gets unloaded or anyway the "right" next track starts playing?

[roderickvd]

As SmallRng is being used by the ditherer, you could consider using that. It provides sufficient randomness and may help keep the binary a bit less inflated.

[photovoltex]

So I changed it up to use small_rng. But I don't think it will currently decrease the binary size as other parts of the library includes rand without disabling the default features. By which we don't disable the std feature of rand which includes the other dependencies. Might be a issue to resolve later tho.

[photovoltex]

Question: when you shuffle or unshuffle, while you already have the next track preloaded for gapless playback, how do you manage that gets unloaded or anyway the "right" next track starts playing?

Comment from player.rs in handle_command_load:

// Now we check at different positions whether we already have a pre-loaded version
// of this track somewhere. If so, use it and return.
...
// If we don't have a loader yet, create one from scratch.

It seems like we only use a preloaded track when the next track to load is a preloaded track. So we will load load the track in real time in that case. I think that is pretty fair, when you decide so late that you might not want to shuffle anymore.

If the preloaded track wasn't the requested track to play, it is replaced by an empty state and by that dropped.