Bug: iOS Browsers

[NemanjaLugi]

Hi,

I have a small bug when I want to auto-start the audio player when the widget is open. An audio player starts but without sound. The player works, stream position and duration are displayed, play/pause buttons work.

This works on browsers for both desktop and android devices, but on iOS Safari or Chrome don't.

Do you have an idea of why or some suggestions?

[ryanheise]

I'm not sure why that would be. Have you tried firefox for iOS?

[NemanjaLugi]

Yes, it's the same case like on others. Also, I have tried to play, then to seek and still, there is no sound.

[ryanheise]

This plugin uses HTML5 audio which I assumed would have more universal support, but this is a total mystery. I may make a WebAudio option in the future (although in my experience this runs into more problems with CORS).

If you find another Flutter plugin that does solve the problem for you, let me know and I'll adopt their solution.

[ozz-rjq]

@NemanjaLugi did you solve this issue?

[NemanjaLugi]

No, it is still a total mystery.

[ryanheise]

As mentioned above, it is also a total mystery to me, but if you are able to find another Flutter plugin or even JS library or JS-based web app that works, I may be able to learn from that and fix it in just_audio.

[twogood]

On iOS Browser and Safari on Mac OS I get this exception when play is called:

NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.

Could it be the same thing? Because I wanted to play directly after navigation to a screen, not on a user interaction like a button press.

[twogood]

In Chrome I get this in some cases and I'm find with that - if there was a way to catch this error!

Error: NotAllowedError: play() failed because the user didn't interact with the document first. https://goo.gl/xX8pDD

at Object.createErrorWithStack (http://localhost:45871/dart_sdk.js:5348:12)
at Object._rethrow (http://localhost:45871/dart_sdk.js:39350:16)
at async._AsyncCallbackEntry.new.callback (http://localhost:45871/dart_sdk.js:39344:13)
at Object._microtaskLoop (http://localhost:45871/dart_sdk.js:39176:13)
at _startMicrotaskLoop (http://localhost:45871/dart_sdk.js:39182:13)
at http://localhost:45871/dart_sdk.js:34689:9

Anyone knows how to catch this so that my Dart code can handle it with for example try/catch around audioPlayer.play() ?

[ryanheise]

I think I have seen this before and as far as I can tell, it can be avoided so long as you don't automatically play when the page loads, but wait until after the user has interacted with the page. It seems according to the log a browser policy. As to whether you can catch it, maybe you can try experimenting with this?

I.e. if you clone this repo and point your app the depend on that copy of the web plugin specifically, you could experiment with trying to catch the error within the plugin. And if that's possible, then it can be propagated back to the app.

[twogood]

Yes this is on page reload, but the same works when I navigate to the page in Chrome desktop but not on Safari or iOS. So if I just could catch the error I could add an interactive step when needed.

[ryanheise]

As above, I would recommend experimenting with it yourself, and see if you are able to catch it within the plugin, and if you discover a way to, hopefully you can consider making a code contribution (or at least share below what you discover).

[twogood]

I'm on it :)

[twogood]

@ryanheise please have a look at PR #352 at your leisure

[ryanheise]

Awesome! I'll take a look.

[ryanheise]

@twogood I have merged your PR and published it in release 0.7.2. Thanks for the contribution!

As for the original issue, maybe this behaviour of Chrome suggests that we might not be able to solve this problem universally for all browsers, particularly if browsers have a policy against starting music without a user interaction.

[twogood]

@ryanheise Thank you! Yes, browsers will always have some specific issues like this.

[ryanheise]

@NemanjaLugi On the iOS browsers you're testing with, I'm curious to know, does it work if you accept a user action before playing?

[NemanjaLugi]

@ryanheise I don't remember at the moment, but I think I tried it and I still had a problem with this. After that, I made some changes to the design of the app to avoid this case.

[ryanheise]

Shall we close this issue? I'm not sure if it can be solved, but if someone can post below another app or library that manages to get this auto-play behaviour working on iOS browsers, I could reopen...

[dernoun]

@ryanheise I can confirm that on iOS safari, the problem is on auto play, when I remove it, the video started normally but the processing state keeps buffering at the end of the video!

[ryanheise]

I'll close this issue following on from my previous comment. @dernoun I recommend you open a new issue to describe that particular bug.

[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.