Change ShuffleOrder to only iterator-like methods to allow custom orders with repeated elements

[pawaom]

Can we detect The PlayerNotificationManager/MediaSessionCompat previous/next/play/pause button clicks

I want to implement a custom ShuffleMode , the player.setShuffleModeEnabled(true); sets random songs to play , but I want to implement my own custom logic

for the normal player I am not using exo_playback_control_view, but a custom control view , from which i call custom methods for next and previous in the AudioPlayerservice , I want to call these method from the notification aswell, there is an option to create custom notification and medediasession, but It will be easy to call the button clicks from both exo_playback_control_view and PlayerNotificationManager

Can we detect button clicks from PlayerNotificationManager/MediaSessionCompat/exo_playback_control_view

[marcbaechinger]

The ConcatenatingMediaSource has a constructor which lets you inject your own ShuffleOrder object. I think this would be the best solution for implementing your own custom logic. With this you don't have to detect clicks for every UI component. They just work as before and your custom ShuffleOrder can define the logic.

Have you already considered this approach?

[pawaom]

thanks for the reply, I want to know this part,

When we use,ShuffleOrder the thing is with shuffle does not have the REPEAT_MODE_ALL kind of option, it just has the REPEAT_MODE_OFF kind of option

Like when we should have this option as well, Say like when the first Cycle is over we should have an option to start an new cycle,

example we have songs a,b,c,d,e,f,g now we have ShuffleOrder in sequence of 2,0,6,1,3,5,4 so now when the currentwindowindex of 4 that is song e is played the player would not go further , I know this is intended behavior, one option is to go back to the first index of 2 and repeat the same shuffle order but can we again randomize the order and start a new sequence(cycle) while maintaining the history of previous songs from the first cycle as well so that when the user clicks previous button he gets the previously played songs as well

[tonihei]

In addition to ShuffleOrder, you can also use player.setRepeatMode to repeat the shuffled playlist. The player then loops the shuffled playlist as it is.

If you'd like to change the shuffled order after looping, you can listen to onPositionDiscontinuity to see when the player loops to the first item in the list, and then set a new ShuffleOrder by calling ConcatenatingMediaSource.setShuffleOrder. This order can be different from the previous one and you can provide your own initial order in the constructor to, e.g., keep the current item as the first one in the list.

Note that this class isn't meant to keep an infinite list of previously played items, so if you want to support going back to a previous shuffle order, you probably need to keep track of the already played items and reassign the previous shuffle order if needed. Would that work for you?

[pawaom]

this might help thanks, will give it a try, hope there was an easier way to manage multiple shuffled playlists

so if you want to support going back to a previous shuffle order, you probably need to keep track of the already played items and reassign the previous shuffle order

this gets me back to my previous question I want to detect the previous/next clicks at least from the PlayerNotificationManager/MediaSessionCompat

[tonihei]

this gets me back to my previous question I want to detect the previous/next clicks at least from the PlayerNotificationManager/MediaSessionCompat

I think you need to listen to onPositionDiscontinuity to detect that.

[pawaom]

thanks @tonihei can manage multiple shuffled playlists be a feature request

[tonihei]

I think it's quite a niche use case, but it should probably be a ShuffleOrder that works more like an iterator than a random access array. Because as soon as you allow the concept of having the same item multiple times in an potentially infinite order, you can't query by index anymore. For example, getNextIndex(5) can't be answered in a meaningful way because it's unclear to which repetition this index belongs to. On the other hand, we might not need this functionality because no known caller currently uses this random-access option.

Having said that, we are thinking about moving all of the playback order logic together into one class (i.e. shuffling, looping, and any customizations) and it's worth taking this requirement into account.