Closed tsheaff closed 6 months ago
For now my application is going to assume that State.Buffering
always means this "play buffering" case since that's far more common, and I'll need to add more strict idempotency guarantees (which adds a decent amount of complexity for me) in a number of call-sites. So the impact here on my application is notable. I'm guessing it's this way for others.
Was there a discussion about why this change was made?
Fwiw, I also only want to know about play buffering. I'm already tracking state to know if the app was was previously playing so for me it's not too bad (I think!)
just search state.Buffer and u could find
https://github.com/doublesymmetry/react-native-track-player/issues/2036
Thank you @lovegaoshi I did not find this in my searching of the docs or github, but I was using the wrong keywords.
This PR is the solution here: https://github.com/doublesymmetry/react-native-track-player/pull/2040
Closing
What is the need and use case of this feature? Prior to v4, the
State.Buffering
state always meant it's buffering while trying to play. My application relied on this behavior.In the v4 upgrade notes, it says
State.Buffering Updated. Now emitted no matter whether playback is paused or not.
I would like a way to tell this very important distinction. In certain core cases (e.g. when I'm recording "play intervals" to my local database), this distinction is not incidental, it's a very imporant distinction. Unless I'm missing an API, there's currently no way for me to tell the difference between these two different types of buffering, other than maintaining a full history of the state updates myself and doing a very complex and brittle logic
Describe the ideal solution Bring back the distinction between "Play Buffering" versus "Pause Buffering"
Describe alternatives you've considered Trying to calculate this myself by looking at the full history of state changes, but with multiple tracks this quickly gets very complex and brittle
How I can Help Happy to help however I can!