Just_audio: shuffle and looping functionality

[mohammadne]

Which API doesn't behave as documented, and how does it misbehave?
on shuffeled mode when it's true and:

1. when we call player.seekToNext
2. when we request to seek to a new index

Minimal reproduction project
"The example"

To Reproduce (i.e. user steps, not code)
Steps to reproduce the behavior:
1.in example project, set shuffeled mode to true

1. play

Error messages
there isn't any error, I think the implementation is wrong.

Expected behavior

1. when we call player.seekToNext, the player should seek to the next AudioSource in its shuffled list, not the next AudioSource (same for player.seekToPrevious)

1. when we request to seek to a new index, the shuffeled list should be recreated because suppose a scenario when our shuffled list order is: 0 --> 2 --> 3 --> 1, if we request a seek index for 1 at very begining, the list will be reached its end, so I think we should recreate the shuffeled list on user manual index seeking.

Describe alternatives you've considered
the alternative is discussed above.

[mohammadne]

Hi @ryanheise

to be honestly, I preferred assigning handling shuffling and looping tasks to the developers.
but because you implemented those features in your library, I think we should have more flexibility to handle them or at least it should meets the above expectations.

Thanks.

[ryanheise]

Hi @mohammadne , yes I agree with expected behaviour (1), and (2) might be a good idea.

to be honestly, I preferred assigning handling shuffling and looping tasks to the developers.
but because you implemented those features in your library, I think we should have more flexibility to handle them or at least it should meets the above expectations.

Shuffling needs to be supported directly by the plugin in order to achieve gapless playback. However, I can consider adding options for custimisability.

[mvolpato]

Hi, is this planned to be fixed?

I see this part (in the iOS Pod) is commented, but it might be the solution. What is the reason why it is commented?

AVQueuePlayer does not implement a goToPreviousItem so I wouldn't know how that would be solved.

[ryanheise]

I was just working on this today. No, that commented out code isn't the solution, all of the code necessary to make this work exists in the platform implementation, but it's just that the Dart side of the plugin currently just translates a seekToNext call into a seek call with the current index plus 1. There are two solutions:

1. Define seekToNext as a special method that needs to pass directly through to the platform side where it can be implemented appropriately on iOS/macOS, Android and web.
2. Define the shuffle order on the Dart side so that Dart can compute the correct index to jump to, and then translate the seekToNext call into an appropriate call to seek.

The advantage of (2) is that @mohammadne 's additional requirement can be satisfied because it will allow defining an API to customize the shuffle order if desired.

Speaking of that, @mohammadne if you have any thoughts on what I've proposed with regards to customising the shuffle order, let me know.

I can't say this would be quick to implement, but a workaround would be to call seek with a random index as a parameter yourself. It's not perfect, but it could give the illusion that things are working properly.

[ryanheise]

@mohammadne , out of curiosity, what sort of control would you like to have over the shuffle order?

[ryanheise]

The most recent commit to git master should address these issues.

I have created a class called ShuffleOrder which you can subclass to define your own shuffle order logic and pass into ConcatenatingAudioSource (or use DefaultShuffleOrder).

seekToNext should now seek to the next item in the shuffle order if shuffle mode is enabled.

This is a rather major code change and there's a risk of new bugs, so I would appreciate to hear your feedback from your own testing on whether you run into any issues with it.

[mvolpato]

Thanks for the fix. I am trying to use the master branch from my pubspec with:

just_audio: 
    git:
      url: git://github.com/ryanheise/just_audio.git
      ref: master
      path: just_audio

but it does not seem to work. Do you have some instructions on how to do that?

The error:

Error on line 14, column 11: Invalid description in the "just_audio" pubspec on the "just_audio_platform_interface" dependency: "../just_audio_platform_interface" is a relative path, but this isn't a local pubspec.

Edit:
I cloned the repo and now I use

just_audio: 
    path: ../just_audio/just_audio

Edit 2: @ryanheise If there is some specific behaviour you want me to test let me know, for now I will play with my app and see if something weird happens

[mohammadne]

The most recent commit to git master should address these issues.

I have created a class called ShuffleOrder which you can subclass to define your own shuffle order logic and pass into ConcatenatingAudioSource (or use DefaultShuffleOrder).

seekToNext should now seek to the next item in the shuffle order if shuffle mode is enabled.

This is a rather major code change and there's a risk of new bugs, so I would appreciate to hear your feedback from your own testing on whether you run into any issues with it.

thanks @ryanheise , I will test it today and inform you if there is any bug.

[ryanheise]

Thanks both for testing!

The main thing to test would be that there are no index-out-of-bounds errors, because the playlist indexing logic has changed in Dart, as well as in the iOS code and the Android code (and web). So if it's bug free on Android, it might still have a bug on iOS. I would suggest just using the shuffling and looping code the way you intend to in your app, but then you might want to try clicking buttons in different sequences that would result in the underlying API calls being called in different orders.

[defsub]

@mvolpato I have the following to use git directly:

  just_audio:
    git:
      url: https://github.com/ryanheise/just_audio.git
      path: just_audio

[mvolpato]

@mvolpato I have the following to use git directly:

  just_audio:
    git:
      url: https://github.com/ryanheise/just_audio.git
      path: just_audio

Thanks. That did not work for me 🤷‍♂️
I had to clone the repo and refer to my local copy

[ryanheise]

FYI, I have made another change which will also be part of the next release (#249 ). I mention it here because it is another (minor) API change which might affect you.

If you currently use the load method, you will need to rename this to setAudioSource. If you don't use the load method, your code should be unaffected. However, if you notice any problems, please report them on #249 .

As for the new shuffle functionality, is it working correctly for both of you?

[mvolpato]

I have been playing with it and I did not notice any problem (Android mainly, iOS quickly tested).
The only inconsistency I found is this one:

1. Load a list of audio files
2. Play without shuffle
3. skip to next a couple of time
4. Enable shuffle
5. If you go skip to previous, a random audio will play and not the one that was playing before enabling shuffle.

This is not a big deal, and honestly I do not know if this is the standard behaviour, so maybe I am wrong here.

A colleague of mine has quite some experience with playlist playback and shuffling in iOS native, he will have a look as well soon.

[ryanheise]

That is the behaviour of DefaultShuffleOrder but if you like, you could plug in your own implementation of ShuffleOrder which preserves the order of items before the current index.

[mvolpato]

I will also have a look at #249. I do use load, so I will need to test that also.

edit: I had a look at the changes, and I will need to refactor a bit. I will push it to a later date because we want to release a new version of the app soon.

[ryanheise]

Just to update on my schedule, I'll keep this issue open for testing for approximately half a day longer and then roll out a release if there are no outstanding issues by that time. This will be the last new-feature release before the switch to the null-safe version, and all new features after that are planned to be developer on the null-safe version.

[ryanheise]

0.6.0 has now been released including this feature.