-
-
Notifications
You must be signed in to change notification settings - Fork 597
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bad state Exception when call player.dispose() #183
Comments
I'm having the same problem, when using positionStream:
Disposing the AudioPlayer in dispose() gives me the exact same error as @AhmedNourJamalElDin's above. I did try to drain the stream, in an async dispose(), as below:
But it appears to get stuck in the await and never gets past it, to run the rest of the code. A little bit stuck now! |
Hi @tnaseem @AhmedNourJamalElDin has graciously made a pull request that you can try out (#182 ). Let me know how it goes for you. |
Nice work. That did the trick. :) |
Great to know it works, I'll still need to do some testing across all the platforms. This issue is complicated by the fact that the stream is now closed on the platform side, and so we may see different behaviours across platforms, and if so it may require further thought on whether the platform side should do this.
It would be great to have some automated unit testing for this project eventually, but until then, each bug fix requires the manual creation of a reproduction project specific for that bug to demonstrate the bug and allow testing before and after fixing the bug, if that bug is not reproducible on the example (which is the case here). I appreciate that you contributed a fix so I'd be more than happy to create the missing minimal reproduction project on my end this time (although providing one will help me to get around to merging this a bit sooner). |
I'm wondering then, would it be better to expose ie. Something like:
We can then just do that prior to disposing the audio player ourselves, for these cases. |
@tnaseem I was also thinking of something along those lines. There is also the fact that it is possible for apps to call |
I should mention that the intention of the existing code was to figure out when to call |
Hi @ryanheise , if the users must have access to so we can either
I don't know which is better and I'm not expert at these, but I think giving access to the users is the best option here, what do you think? |
BTW I'm not sure if there is a better way to handle this situation (issue), maybe we don't need to dispose the controller at all, and there is another way to fix this? I tried hard to figure out the issue and this is the fastest way I could overcome it. |
The existing code does try to close every controller automatically as soon as the player is disposed (see line 409 of git master), but there could be a timing issue, and the reason why I didn't notice that timing issue is because I normally call |
(Although I would rather try to understand why this code is failing and do it correctly) |
Possibly, I mentioned elsewhere that it is probably not necessary to close some of these things if the platform side has already given an endOfStream signal on the event channel. As soon as I added that code on the platform side, I noticed some of the closes on the Dart side were failing, so it's a bit of a complicated situation with respect to which part of the code is considered the owner and responsible for closing. |
I think that too. relying on a timer to dispose the controller whereas disposing the subject in dispose method. However I tried to stop the |
I did try the
But it didn't help either, unfortunately. |
I've finally had a chance to create a minimal reproduction project and do some testing. The correct solution is as suspected in the original #169 issue which is to simply delete this line from await _positionSubject.close();
Let me know how that goes, and I'll include this in the next release. |
Perfect, Thanks. |
Just tried it (0.4.4) and it works great. Nice work and thanks! |
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. |
Which API doesn't behave as documented, and how does it misbehave?
disposing the payer throws:
You cannot close the subject while items are being added from addStream
.Minimal reproduction project
No need. any project you have which have player in different screens and when you want to go from screen to another, you have to dispose the running player, you face this issue.
To Reproduce (i.e. user steps, not code)
Steps to reproduce the behavior:
Error messages
Expected behavior
Shouldn't throw exception, and dispose the player normally.
Screenshots
Not needed
Desktop (please complete the following information):
Smartphone (please complete the following information):
Flutter SDK version
Additional context
This is tooooooo weird. how does it happen but not many people notice it? maybe it's incompatible issue with flutter version?
The text was updated successfully, but these errors were encountered: