IOS only - player will not play after reaching end of media and emitting ProcessingState.completed

[fuzing]

Which API doesn't behave as documented, and how does it misbehave? Note - this issue occurs on IOS only. After the player emits ProcessingState.completed, when seeking backwards (anywhere) and attempting to call .play(), the player will not play the audio. Calling any combination of .pause(), .play(), .seek() fails to restart the player.

Minimal reproduction project Happy to work on this and provide if necessary.

To Reproduce (i.e. user steps, not code)

Error messages No errors being emitted.

Expected behavior Would expect that after reaching the completed state, seeking, playing would undo this state (it may be doing this) and allowing playback from earlier in the audio.

Screenshots

Desktop (please complete the following information):

Smartphone (please complete the following information):

• iPad
• OS: IOS 12.4.8

Flutter SDK version 1.21

insert output of "flutter doctor" here [✓] Flutter (Channel master, 1.21.0-10.0.pre.167, on Mac OS X 10.15.4 19E266, locale en-US) [✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2) [✓] Xcode - develop for iOS and macOS (Xcode 11.6) [!] Android Studio (version 4.0) ✗ Flutter plugin not installed; this adds Flutter specific functionality. ✗ Dart plugin not installed; this adds Dart specific functionality. [✓] IntelliJ IDEA Ultimate Edition (version 2020.2) [✓] VS Code (version 1.48.0) [✓] Connected device (1 available)

! Doctor found issues in 1 category.

I'm using VS, not Android Studio, so can ignore issue!

Additional context N/A

[ryanheise]

Hi @fuzing , maybe this should be reproducible in the example if you skip to the last track, seek to just before the end, and let it play out to completion, and then click the seek bar to seek back. In my case, though, it correctly resumes playback. Since it doesn't happen in the example, then yes a minimal reproduction project will be needed.

[fuzing]

Agreed.... thank you for that feedback. I'll download the sample to my IOS device and confirm that it works with my IOS version and hardware combo.... then I'll take a look at the sample code vs. mine for clues. Failing this, I'll assemble a minimum test app.

[fuzing]

Ryan - I'm several days away from being able to focus on this and either replicate or fix, but will get to it next week.

[fuzing]

Just tested this with the just_audio example app and I get the same failure for my device/IOS combination.

Steps to reproduce: Upgrade flutter to latest version (flutter upgrade, flutter clean) Install the just_audio example app (after setting up signing etc., using xcode, or flutter run --release) Run the just_audio example app Select the last item in the playlist (Sci Fri - from Cat Rheology.......) Allow selection to complete by either playing all the way through, or moving the slider near the end of the audio to seek there and allowing it to complete After completion, move the slider backwards anywhere on the track Busy spinner spins indefinitely, won't play

Note: I'm using ipad air and ipad air 2 - both fail, both are on IOS 12.4.8

[ryanheise]

Since I can't reproduce this on the simulator, that may make things difficult on my end, although I think this is important to fix.

If you're willing to work with me, I could try some workarounds and maybe you could test them and let me know if there is any improvement.

[imariman]

I am planning to release my app to App Store & Google Play Stores this week, and if fuzing is not available to focus on this problem as he mentioned above, I can help you to test your workarounds on my real IOS devices too, fyi. I just want to play voice records on my chat app and once user listens the voice record, state change logs are "completed -> buffering" and state stucks at buffering state. User can't listen the voice record twice in my situation.

[ryanheise]

Thanks, @imariman . That would be really helpful. Just to confirm, it transitions to buffering right after reaching completed even without doing a seek like @fuzing did?

[imariman]

Yes. The state changes are below.

1- Processing State: Loading, Playing: false 2- Processing State: Ready, Playing: false 3- Processing State: Ready, Playing: true 4- Processing State: Completed, Playing: true 5- Processing State: Buffering, Playing: true

and it stucks at the 5th situation in IOS. I want to play one voice record (not a playlist), and once I click the replay button, it stucks at circularprogressindicator.

[ryanheise]

Some good news: I am now able to reproduce this on the simulator, so I'll try to fix it now.

[imariman]

I am very happy to hear that! Thank you for your time.

[ryanheise]

I believe I have fixed it. Note that I have implemented this fix on the audio-session branch (which I would like to merge soon, but it needs testing, as mentioned in the pinned issue). You can test it with the following:

  just_audio:
    git:
      url: https://github.com/ryanheise/just_audio.git
      ref: audio-session

[imariman]

It works as it should now. Thank you very much! 👍 💯

[ryanheise]

Glad to hear!

I have just merged this into the master branch. On my end, everything seems to be stable, so I'll probably put out a release soon-ish (maybe within the next hour or two).

[fuzing]

I'm just testing also - will have feedback in about 10 minutes

On Sun, Aug 23, 2020 at 9:59 AM ryanheise notifications@github.com wrote:

Glad to hear!

I have just merged this into the master branch. On my end, everything seems to be stable, so I'll probably put out a release soon-ish (maybe within the next hour or two).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ryanheise/just_audio/issues/152#issuecomment-678791449, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACY4CFMN4WXGHSFEZQJ7WK3SCE4GZANCNFSM4QFOXQ5A .

[fuzing]

Looks good to me - I'll wait an hour or two and then close - or Ryan, be my guest.

Thanks for your work on this. Very quick question - was this an IOS only fix, or did you make mods to code that might impact both IOS and Android? (I ask insofar as I have a similar [albeit different] issue with Android not playing at all, but only after an extended period of time - i.e. I leave the device for a day or so with the background task up, but no foreground - then come back and nothing plays.

Let me know. I'm in the process of trying to replicate in a consistent manner (maybe its gone now?).

[ryanheise]

This was an iOS-only change, so this sounds like it would be a different issue.

One thing I should mention about the audio-session branch (which just just been merged) is that it has been tested only with the audio-session branch of audio_service. I am not sure whether audio focus handling would work if only just_audio were updated and audio_service were not. The reason is that this change moves audio focus management out of audio_service. But if you use the new just_audio and the old audio_service, you'll end up with audio focus handling code in two places.

Thus, I would like to release the two plugins roughly simultaneously, although I would feel more confident about doing that after hearing from people using the new audio_service (audio-session branch).

[fuzing]

Hi Ryan - For my testing (quick and dirty) I didn't bring the two plugins/repos into alignment........ don't think I'll be able to get to that until tomorrow, but will definitely do that and circle back around. Thanks for the heads-up.

[fuzing]

I'll need to pin down exactly what's going on for the Android problem so as not to waste anyone's time. Before attempting to draft a synopsis I'll make sure I'm on the latest versions (or branches/refs if that would be preferable).......

[fuzing]

Ryan - to get the right combination........ Is audio_service -> audio-session branch now merged into master (I can't find an audio-session tag/branch)

[ryanheise]

Yes it has now been merged into master. I realised I didn't actually update the example completely, but the plugin itself should be fine on master. The example should work, although it will by default set up the audio session for music playback, and I had intended to explicitly set it to speech for this example (I am in the process updating the example further.)

[fuzing]

Great - just want to make sure I'm in sync....... Still a little confused about where the interdependencies are vis. simply_audio <-----> audio_service

[ryanheise]

The simplest way to migrate is to remove any audio interruption handlers from your background audio task (if you have any), and then pass handleInterruptions: true into just_audio's constructor to let it handle it.

Everything else is under the hood unless you want to change the default behaviour of the underlying audio session. An audio session controls how an app takes ownership of audio on the device. Depending on the nature of your app, you may want to pause or duck if another app plays audio, or you may alternatively want to cause other apps to duck or pause. The defaults are reasonable for a music app, but if you require special behaviour, you can then use the audio_session package to directly declare your app's audio requirements and how you would like to interact with other audio apps.

The one thing I haven't decided on yet is whether to make handleInterruptions: true the default behaviour for just_audio. The primary reason for defaulting to false is because previous versions of just_audio didn't handle interruptions. But if I think about it, probably it would be reasonable to enable it by default, and let people pass in false if they have more specialised behaviour that they want to implement themselves.

[fuzing]

I'd agree - defaulting to handleInterruptions: true sounds like a reasonable default option..... flattens the learning curve and makes adoption much easier. I can't speak to everyone else in terms of where they're at, but I'm handling those interruptions in "service" and doing what I believe are the appropriate gymnastics with just_audio...... easy for me to change, and I'd be happy to hand that control over.

That being said, others may be surprised/caught off guard if the default is to wrestle away control....... hence if it were me, I'd default to false for this major.minor combination and flip it for the next major (with the appropriate release note) (just my 2 cents).

Thanks for all your help with this. Know that I (and others) really appreciate your efforts.

On Mon, Aug 24, 2020 at 11:26 AM ryanheise notifications@github.com wrote:

The simplest way to migrate is to remove any audio interruption handlers from your background audio task (if you have any), and then pass handleInterruptions: true into just_audio's constructor to let it handle it.

Everything else is under the hood unless you want to change the default behaviour of the underlying audio session. An audio session controls how an app takes ownership of audio on the device. Depending on the nature of your app, you may want to pause or duck if another app plays audio, or you may alternatively want to cause other apps to duck or pause. The defaults are reasonable for a music app, but if you require special behaviour, you can then use the audio_session package to directly declare your app's audio requirements and how you would like to interact with other audio apps.

The one thing I haven't decided on yet is whether to make handleInterruptions: true the default behaviour for just_audio. The primary reason for defaulting to false is because previous versions of just_audio didn't handle interruptions. But if I think about it, probably it would be reasonable to enable it by default, and let people pass in false if they have more specialised behaviour that they want to implement themselves.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ryanheise/just_audio/issues/152#issuecomment-679262279, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACY4CFK2HEUCYB7FK634ZATSCKPGHANCNFSM4QFOXQ5A .

[ryanheise]

That was my original thinking, and I was originally planning a phased approach with the next release of just_audio being perfectly backward compatible with the old version by default. However, just defaulting handleInterruptions to false doesn't alone make it backward compatible, although I had initially hoped it would. A truly backward compatible version would look quite ugly because it would have to emulate the fact that the old version of just_audio handled things inconsistently on Android and iOS. That is, the old version did audio session management for iOS but not Android.

But theoretically it would be possible if I had a constructor that looks like this:

AudioPlayer({handleInterruptions: false, backwardsCompatible: true});

And internally do some horrible looking code that people won't see.

Then in audio_service I could add back in the audio focus callbacks and deprecate them.

[fuzing]

Ryan,

Do you want me to close this? I think this is fixed.

Ugggh...... that's the problem with backward compatibility. At some point you just have to increment the major and move on...... screams willl fade eventually (earplugs are good) and the codebase and plugin will be cleaner/better for it, and you'll sleep better. This project has moved quickly and as long as the left behind version can be minor patched I think most people get it. You're one person, not a team of 20. Well done.

[fuzing]

BTW, my android issue was as a result of an exception being thrown due to my code in onClose() in the derived background task class..... resulting in super.onClose() not being called - my fault......

[ryanheise]

Which onClose is this? If it is audio_session, I should mention that ideally I would like to get rid of this method and have the cleanup handled automatically by the plugin.

[ryanheise]

Ah, I see you mean in audio_service.

[fuzing]

Yes - in audio_service - sorry. I'm calling directly on Android swipe-away.

On Mon, Aug 24, 2020 at 9:04 PM ryanheise notifications@github.com wrote:

Ah, I see you mean in audio_service.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ryanheise/just_audio/issues/152#issuecomment-679484565, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACY4CFNKXBKD4Y6BIJV374TSCMS3BANCNFSM4QFOXQ5A .

[ryanheise]

OK, I'll close this issue then, and thanks for the perspective on backwards compatibility. I'll ponder it further, and a proper release will probably happen in a day or two.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs, or use StackOverflow if you need help with just_audio.