Open oseiasmribeiro opened 2 years ago
Oops, it appears that your issue did not follow the template and is missing one or more required sections. Please open a new issue, and provide all required sections and information.
FAQ:
Do I really need to submit a minimal reproduction project for a bug? A: Yes. I prioritise bugs secondarily on how many people are affected, and primarily on whether the bug report is complete, in the sense that it enables me to immediately reproduce it and start working on a fix. If a bug is important to you, the best thing you can do is to provide all requested information ASAP so that I can start looking into it ASAP.
I think I supplied all required information, so did the bot make a mistake? A: The bot only checks the section headings, so when you post a new issue, make sure you leave the section headings intact. (Note that because of this, it is even possible to trick the bot by including only the section headings, and then not providing the requested information under each heading. This is frowned upon, and the issue will be closed manually.)
Can you update your issue with the correct link to the previous issue?
Just post the Issue link? if it is the Issue #648
Ah sorry the link was already correct! My mistake.
As for the issue, I'm afraid I still don't have any further leads, though. I have also only tested Chrome. Have you tested other browsers to see if this is unique to Chrome?
I did it now. Safari: Versão 15.3 (17612.4.9.1.8) ---------------------------- is working Edge 99.0.1150.46 (Compilação oficial) (x86_64) ------------- not working
In Edge, although the bug is the same, the behavior is different from Chrome. After Play it no longer returns "Ready'.
Hello! I'm having the same issue in Safari, first the state is Ready, and then changes to Buffering, and it doesn't goes back to ready. Safari version: 15.4 (17613.1.17.1.13)
@ryanheise, maybe this could have something to do with the problem • https://stackoverflow.com/questions/10235919/the-canplay-canplaythrough-events-for-an-html5-video-are-not-called-on-firefox • https://stackoverflow.com/questions/36178278/how-could-i-check-if-canplaythrough-is-true • https://stackoverflow.com/questions/5204736/canplaythrough-event-and-htm5-audio-can-anyone-remove-this-event • https://qa.ostack.cn/qa/?qa=556792/
That looks very helpful! Basically the first link suggests it's a timing issue. However, you can see in the code that this plugin does register the callbacks.
The second link suggests you actually need to poll ready state since canplaythrough is only going to get called once after the entire audio is loaded...
I guess the second approach, while inelegant, is the only way to get it to work on firefox.
So, as I understand it, the only way is to check if "Playing" is False or True and disregard the player's status. I tested it on the latest version of Edge and Chrome, it doesn't work. @anfernandezz also tested it on Safari, it gives the same problem.
It wasn't clear to me that @anfernandezz tested the workaround in the second stackoverflow link before you shared that link. But just to be clear, that is what is being tested here? e.g. you have modified just_audio_web to periodically query _audioElement.readyState
?
Sorry, I didn't explain correctly. The tests I mentioned were done a few months ago with Just_Audio version 0.9.20 on Chrome. With the current version of Just_Audio 0.9.21, I tested it in Chrome, Edge and Safari, all give the same problem. These tests were done without changing the source code (I don't really understand how to modifier the Just_Audio_Web package). It's weird that "canplaythrough" doesn't work on the web, I always get a return of "ProcessingState.ready" after Stop and Play on Android and iOS. @anfernandezz also tested this before the links.
OK, then my previous response still applies, and the second link, while inelegant, seems like the only way to get it to work.
@ryanheise Could you give me some help with a code example of how to use the "second link" with Just_Audio?
To be clear, the solution requires modifying just_audio_web.
Ok. I'm waiting. Thanks!
May I ask if there is a solution to this problem? I also encountered this problem when I used just_audio: ^0.9.30
There is a solution approach discussed above, but someone needs to tackle that and implement it into just_audio_web (and it doesn't have to be me - contributors are welcome if you'd like to help make it happen sooner.)
I'm creating a new Issues because the other one ( #648 ) was automatically blocked, and I consider this bug in Chrome a big problem. I've done a lot of research on Javascript's "canplaythrough" and "waiting" events, but I couldn't understand the reason to be able to help.
Which API doesn't behave as documented, and how does it misbehave?
just_audio: ^0.9.20 audio_session: ^0.1.6+1
There is different behavior in returning state using Flutter Web in Chrome compared to Android and iOS. After initializing the audio it reaches the "ready" state. After "Play" and "Stop" it reaches the "idle" state. After "play" again, it goes through the "loading" state and stops at "buffering". It doesn't get to the "ready" state again.
Code snippet where I print the state stream:
Repo https://github.com/oseiasmribeiro/webradio.git
To Reproduce (i.e. user steps, not code) Steps to reproduce the behavior:
Error messages In Chrome browser after "Play" and "Stop" and "Play" again, the state is only in "buffering":
Expected behavior On Android and iOS it is behaving as expected:
What is desired is that the state does not stop "buffering" because in this way it is not possible to show the buttons correctly.
Screenshots https://user-images.githubusercontent.com/36827173/152571940-95cb270c-4364-45c7-a379-bb800747d19e.png
Desktop (please complete the following information):
Smartphone (please complete the following information):
Flutter SDK version
Additional context There is not.