I have searched and made sure there are no existing issues for the issue I am filing
[X] I have searched the existing issues
Description
When checking if a player using Ti.Media.createAudioPlayer is paused, there's a chance that it returns false even though I have paused it already. When analyzing the source I believe I found the issue to be because the properties checks against the locally stored _state, which is also used to store buffering information so it sometimes gets overwritten by this.
I'm currently evaluating this change, but I'm not sure if it's the best change or if it might cause any side-effects:
This might affect more properties, as I noticed more of them are checking against _state instead of _player.timeControlStatus.
Expected Behavior
I expect the property to return true when the player is paused.
Actual behavior
It returns false, and the state property returns that it's buffering.
Reproducible sample
I currently don't have a reproducible sample, so I'm not sure exactly if it always appears or if the buffering state happens because of the scenario I'm using:
The player is playing local mp3-files stored in Resources
There are multiple players playing simultaneously, one for background audio, one for foreground audio
Steps to reproduce
We noticed the issue when we wanted to check if the player was paused or not for a Play/Pause toggle. It doesn't happen all the time, which is part of why I haven't been able to make a reproducible sample yet. I'm open for suggestions if someone knows how to reliably trigger the buffering event to make this more easily testable.
I have searched and made sure there are no existing issues for the issue I am filing
Description
When checking if a player using Ti.Media.createAudioPlayer is paused, there's a chance that it returns false even though I have paused it already. When analyzing the source I believe I found the issue to be because the properties checks against the locally stored
_state
, which is also used to store buffering information so it sometimes gets overwritten by this.I'm currently evaluating this change, but I'm not sure if it's the best change or if it might cause any side-effects:
This might affect more properties, as I noticed more of them are checking against
_state
instead of_player.timeControlStatus
.Expected Behavior
I expect the property to return true when the player is paused.
Actual behavior
It returns false, and the state property returns that it's buffering.
Reproducible sample
I currently don't have a reproducible sample, so I'm not sure exactly if it always appears or if the buffering state happens because of the scenario I'm using:
Steps to reproduce
We noticed the issue when we wanted to check if the player was paused or not for a Play/Pause toggle. It doesn't happen all the time, which is part of why I haven't been able to make a reproducible sample yet. I'm open for suggestions if someone knows how to reliably trigger the buffering event to make this more easily testable.
Platform
iOS
SDK version you are using
12.4.0.GA
Alloy version you are using
No response