ryanheise
Player returning 0 position and duration data in certain circumstances(iOS Only)
Since the #1418 issue has been closed automatically I duplicated the issue here.
Which API doesn't behave as documented, and how does it misbehave? Playing certain audio files on iOS while using LockCachingAudioSource breaks the position and duration streams, making them return 0.
I have not been able to find a link between the audio files that don't work. Most do, some don't. Worth noting that this behavior only happens when using LockCachingAudioSource, any other audio source is fine.
Also worth noting that this only happens when the player is in a playing state, when you pause the player position data returns correctly, whenever you resume it goes back to 0.
UPDATE It seems the issue is happening on links that redirect you multiple times. In my case, this specific link redirects me 5 times before landing on the original audio file. The solution I have implemented is to resolve the URLs myself, get the final link, and pass that to the player, instead of passing the link I have and let the player handle the redirects itself.
I can confirm that this solution is working for me now, but it isn't ideal. The player should be able to handle this by itself.
Minimal reproduction project The example. Please find below a link to an audio file that causes the above behavior.
https://pdst.fm/e/pscrb.fm/rss/p/mgln.ai/e/1390/traffic.megaphone.fm/FLIGHTSTUDIOGROUPLTD4700555365.mp3 To Reproduce (i.e. user steps, not code) Steps to reproduce the behavior:
Build the app Run the caching example Play the audio The seekbar is broken because position and duration data is null Expected behavior The player should return accurate position and duration data.
Smartphone (please complete the following information):
Device: iPhone 16 Pro Simulator / iPhone 11 OS: iOS 18 / iOS 18.3.1 Flutter SDK version Flutter 3.27.3
Doctor summary (to see all details, run flutter doctor -v): [✓] Flutter (Channel stable, 3.27.3, on macOS 15.2 24C101 darwin-arm64, locale en-LB) [✓] Android toolchain - develop for Android devices (Android SDK version 35.0.0) [✓] Xcode - develop for iOS and macOS (Xcode 16.0) [✓] Chrome - develop for the web [✓] Android Studio (version 2024.2) [✓] VS Code (version 1.97.2) [✓] Connected device (4 available) [✓] Network resources
• No issues found!
@jsfsarkis, we added the Accept-Range header to response headers but nothing changed.
Probably what the plugin should do is follow the redirects up front, remember the root URL, then handle subsequent range requests on the remembered root URL.
For me, the issue occurred on Android. I am using this direct URL https://d3l7rzkmpeo7hj.cloudfront.net/media_upload_147_1745248599.mp4 Duration of the video is about 18 minutes.
It doesn't return duration, so the seekbar remains frozen. You can reproduce this by running main.dart from the example app.
Note: Smaller video works pretty well though.
I’m experiencing the same issue. Both AudioPlayer().positionStream and AudioService.position are behaving incorrectly in the same way.
@ryanheise hi，I had the same problem. I had a minimum repeatable demo.PositionStream does not work on iOS and arm M3 macos chips, but works on x86 macos and x86 iOS emulators. Here is my minimal replication repository: https://github.com/xiaoxin-sky/just_audio_mini_demo
position update by platform.playbackEventMessageStream when play or pause
https://github.com/ryanheise/just_audio/blob/b59061e263e44bbc9da0825393d39d60ecd214dc/just_audio/lib/just_audio.dart#L1574
Hi @ryanheise,
First of all, thanks for your great work on this package!
I’ve come across some additional issues that might be platform-specific.
I found that the result value is correct, but there's a difference in behavior across platforms:
On x86 macOS, playbackEvent.duration is null.
On ARM macOS and iOS, playbackEvent.duration is Duration.zero.
Here’s the relevant line: https://github.com/ryanheise/just_audio/blob/b59061e263e44bbc9da0825393d39d60ecd214dc/just_audio/lib/just_audio.dart#L669
Based on my testing, changing this line resolves the 0 position issue on arm macOS and iOS, although I’m not sure if this is the ideal solution:
playbackEvent.duration == null || playbackEvent.duration! == Duration.zero || result <= playbackEvent.duration!
Just wanted to bring this to your attention in case it helps. Thanks again!
The solution above does indeed seem to fix the issue with the position stream updating. It, however, does not fix the issue with duration stream not updating and therefore leads to not being able to display a seek bar correctly as the duration of the audio source does not come through. I have not been able to pinpoint in what situations this issue occurs as the occurrence is quite random.
Calling the load method before play does throw an error in the situations where duration was not being returned so I am able to allow the user to retry playing the audio source and the audio source is correctly loaded along with the duration on the second try.
I'm quite confused about this issue. The song can play normally, but the progress display is abnormal. After debugging the code, I found that the listening of the positionStream is not triggered. However, this is not the case for all songs—it mainly occurs when a URL that has never been played before is loaded for the first time. Is there anyone who can help me sort out this problem and, if possible, give me some suggestions? Thank you very much.
