In certain cases audio can be paused due to queue methods

[puckey]

While browsing through the source code, I have seen what I perceive to be a mix-up between only doing something when the audio is playing and only doing something when the play will play.

The android version of skip will only play the item when ready if the player was already playing when the function was called : https://github.com/doublesymmetry/react-native-track-player/blob/9ed308c2a8f5bbd4ab69df01a7cfb86047960538/android/src/main/java/com/doublesymmetry/trackplayer/service/MusicService.kt#L250-L253

Instead of passing player.isPlaying here – I guess we would want to pass the underlying value of exoPlayer.playWhenReady

Same goes in the iOS version – the call to player.jumpToItem passes playWhenReady: player.playerState == .playing: https://github.com/doublesymmetry/react-native-track-player/blob/27b85b72d85c5347ce9205d8b0bd1b5b433f34f3/ios/RNTrackPlayer/RNTrackPlayer.swift#L385-L411

In the add function, the current playWhenReady value will be overridden to false on first call to an empty queue, even if it was true by a previous call of play()

https://github.com/doublesymmetry/react-native-track-player/blob/27b85b72d85c5347ce9205d8b0bd1b5b433f34f3/ios/RNTrackPlayer/RNTrackPlayer.swift#L347-L349

[puckey]

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

[puckey]

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?

[puckey]

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)
• QueuedAudioPlayer#jumpToItem(index: Int)
• QueuedAudioPlayer#add(item: AudioItem)
• QueuedAudioPlayer#add(items: List<AudioItem>)

SwiftAudioEx:

• QueuedAudioPlayer#load(item: AudioItem)
• QueuedAudioPlayer#add(items: [AudioItem])
• QueuedAudioPlayer#add(items: [AudioItem])
• Remove playWhenReady arguments from calls in QueuedAudioPlayer#next() and QueuedAudioPlayer#previous()
• QueuedAudioPlayer#jumpToItem(atIndex index: Int)
• Remove usage of playWhenReady in QueuedAudioPlayer#AVWrapperItemDidPlayToEndTime

And then switching over any usage in RNTP of above methods without playWhenReady arguments

[puckey]

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 to unexpectedly become paused in certain situations. I came to the conclusion that we should remove all mutations of playWhenReady, except for in the play, pause and stop functions.

[jspizziri]

@puckey , so this is a larger issue than I initially thought (I thought it was only Android). However, I agree, the problem on Android at least seemed to be the result of setting the state of playWhenReady after it had already been set.

Perhaps playWhenReady should only be mutated if an option is specifically configured on the player (e.g. updateOptions).

This is something that will really require the thought of @mpivchev and @dcvz before confirming the correct approach.

[puckey]

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

[jspizziri]

@puckey I closed https://github.com/doublesymmetry/react-native-track-player/issues/1513 in favor of this issue since it looks at both Android and iOS.

I'll note here that there was an initial PR to fix this on the Android side here: https://github.com/doublesymmetry/KotlinAudio/pull/29. However, @puckey has a clearer vision on a better fix.

[jspizziri]

@puckey , I found an old issue which seems to me to be exactly what you're addressing. Could you confirm?

https://github.com/doublesymmetry/react-native-track-player/issues/1356

[praisedavid787]

Hi guys, @jspizziri @puckey, just to confirm speculation, I noticed recently that buffering triggers a pause, could be as a result of the issues you've noticed and probable cause of #1356.

[puckey]

Fixed in https://github.com/doublesymmetry/react-native-track-player/pull/1713

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.