`setSourceUrl` broken since 5.2.0

[putnokiabel]

Checklist

• I read the troubleshooting guide before raising this issue
• I made sure that the issue I am raising doesn't already exist

Current bug behaviour

When calling audioPlayer.setSourceUrl(url), it throws an exception PlatformException(DarwinAudioError, Failed to set source. For troubleshooting, see https://github.com/bluefireteam/audioplayers/blob/main/troubleshooting.md, AVPlayerItem.Status.failed on setSourceUrl, null) on iOS (it throws a different error with the same description on Android as well).

Expected behaviour

audioPlayer.setSourceUrl(url) completes without throwing an error.

Code sample

Code sample

Future<void> main() async {
  final audioPlayer = AudioPlayer();
  await audioPlayer.setSourceUrl('https://firebasestorage.googleapis.com/v0/b/obedience-app.appspot.com/o/audio%2F5e31ff82-e6fc-4837-87e3-aadd4b238c08.mp4?alt=media&token=8b849da9-9a92-4378-88b8-19fea933ed44');
}

Affected platforms

Android, iOS

AudioPlayers Version

5.2.0

Build mode

debug, release

Audio Files/URLs/Sources

https://firebasestorage.googleapis.com/v0/b/obedience-app.appspot.com/o/audio%2F5e31ff82-e6fc-4837-87e3-aadd4b238c08.mp4?alt=media&token=8b849da9-9a92-4378-88b8-19fea933ed44

Related issues / more information

The exact same code and the same URL are working when I'm using version 5.1.0, the bug only occurs on 5.2.0.

[putnokiabel]

Upon looking into the code changes between 5.1.0 and 5.2.0 I now see that the plugin URL-encodes the URL provided to audioPlayer.setSourceUrl(url) (which is already URL encoded).

This does not seem like the responsibility of the audioplayers package to me, IMO it would be better to either:

• just take a string URL and leave it up to the user of the package to encode it as needed (just like in 5.1.0 and before),
• require a Uri instead of a String so the format of the input URL string is always the same, or
• if for some reason you really want to take a string as an input and encode it, add a check to make sure the URL isn't URL-encoded already.

What do you think?

[Gustl22]

@putnokiabel there are many "false" user reports, which have the problem of unencoded url. So it is now encoded by default. To circumvent the problem of encode an already encoded url, it is decoded before. But maybe I missed a case. I'll check next week. Thanks for the report!

[putnokiabel]

@Gustl22 I see how the user reports with unencoded urls would be annoying.
Another alternative (aside from requiring a Uri which would circumvent the problem altogether, though it is a breaking change) might be to check whether the URL is encoded, and if not, throw an error describing that the url needs to be encoded (since one might argue that the method throwing an error is the "correct" behavior when the user supplies an incorrect url).
Just a thought!
Thank you for looking into the issue either way! 😄

[ivanfemia]

I just started experiencing the same issue today

[Gustl22]

I merged a fix for that, but I don't know, when and with what other changes we will release this. Until that you can use the current main branch as follows:
https://github.com/bluefireteam/audioplayers/blob/main/contributing.md#current-development

[putnokiabel]

Great, thanks @Gustl22 ! 😄