@rohitjoins @icbaker any chance one of you could take a look?

@marcbaechinger ping since it has been a month, any chance you could take a look at this PR?

I'm going to send this for internal review now. You may see some more commits being added as I make changes in response to review feedback. Please refrain from pushing any more substantive changes as it will complicate the internal review - thanks!

Ok, I think I've wrapped my head around what this does. Sorry for the wait and for me being slow.

Currently, when items in the playlist are moved, the shuffle order is kept the same. With your change ExoPlayerImpl calls cloneAndMove(). This makes sense to me as this is consistent with what we do.

but a seperate "move" API is needed for my usecase.

Yeah, acknowledged adding cloneAndMove and calling this in ExoPlayerImpl makes sense to enable re-shuffling upon such an operation.

that shuffle order may decide to not reshuffle in the individual items when a group of items is moved.

I agree with this, but my conclusion would be that the default implementation is a no-op? This would have the advantage that we do not introduce a behavior change to what ExoPlayer is currently doing when a move is performed.

This would still be useful for your use case as I understand you have your own implementation of ShuffleOrder and you can then implement cloneAndMove() to actually re-shuffle.

I guess I'm going to change that accordingly unless you have some strong argument to inverse that procedure.

1. Add cloneAndMove() to ShuffleOrder. Make the default implementation a no-op
2. Call the method in ExoPlayerImpl so a custom implementation can re-shuffle in case that's desired.

Sounds good to me, thanks :)

Thanks, Marc :)