Jonathan Puckey

This is another example of a user running into this issue – https://github.com/doublesymmetry/react-native-track-player/issues/1692 and I wouldn't be surprised to these being reposted over time when closed. User tests using a...

Here is a pr that implements this feature request: https://github.com/doublesymmetry/react-native-track-player/pull/1734

Please try the nightly version – it includes a possible fix for this issue: https://github.com/doublesymmetry/react-native-track-player/commit/1b5bb02bbe1457902949ebd9c29829ba4998eb07 `in usePlaybackState avoid possible race condition where setPlayerState could override the value received from the...

I am also seeing missing events still. I think the fix mentioned doesn't actually fix the underlying issue, which is a case of player state events overriding each other. Will...

Should be fixed completely by https://github.com/doublesymmetry/react-native-track-player/pull/1713

The Android implementation of `add(tracks)` looks like it will always pause playback when called: https://github.com/doublesymmetry/react-native-track-player/blob/9ed308c2a8f5bbd4ab69df01a7cfb86047960538/android/src/main/java/com/doublesymmetry/trackplayer/service/MusicService.kt#L204-L207 causing `exoPlayer.playWhenReady = false` in QueuedAudioPlayer#add(items): https://github.com/doublesymmetry/KotlinAudio/blob/5887c86181d63f525b91c9b028d3052e858b087b/kotlin-audio/src/main/java/com/doublesymmetry/kotlinaudio/players/QueuedAudioPlayer.kt#L112-L118

Wouldn't the best route be to discard all setting of `playWhenReady` and just have the last call to `play`, `pause` or `stop` define whether tracks will play after loading?

The work needed to fix this comes down to creating function overloads for the following KotlinAudio and SwiftAudio – leaving out the `playWhenReady` argument: KotlinAudio: - [`QueuedAudioPlayer#load(item: AudioItem)`](https://github.com/doublesymmetry/KotlinAudio/blob/5887c86181d63f525b91c9b028d3052e858b087b/kotlin-audio/src/main/java/com/doublesymmetry/kotlinaudio/players/QueuedAudioPlayer.kt#L65) - [`QueuedAudioPlayer#jumpToItem(index:...

The thread on this issue might be a bit... wandering.. But it comes down to the problem that various queue functions are setting `playWhenReady` to wrong values, causing the queue...

Following the current API of RNTP there is no reason to mutate `playWhenReady` except for in `play()`, `pause()` and `stop()`. Here is the pull request for the SwiftAudio side: https://github.com/doublesymmetry/SwiftAudioEx/pull/22