I have found on iOS that when I return the app from the background to the foreground while the player is paused, that the state.duration of the ProgressComponent is reset to 0. It is as if TrackPlayer has forgotten the duration while the app was paused in the background.
The issue does not happen on the iOS simulator, only an actual device. The issue also does not happen when returning the app to the foreground while the TrackPlayer is playing.
Does this make sense? Is this a known behavior? Or does it sound like a bug in my code?
My bad, the issue was related to the remote-duck event listener I implemented, which was calling stop on the track when returning to the foreground. I had the following:
TrackPlayer.addEventListener('remote-duck', (x: any) => {
const { paused, permanent } = x
if (permanent) {
PVTrackPlayer.stop()
} else if (paused) {
PVTrackPlayer.pause()
} else {
PVTrackPlayer.play()
}
})
Which I thought was exactly how the documentation says I should setup remote duck:
When the event is triggered with permanent set to true, you should stop the playback.
When the event is triggered with paused set to true, you should pause the playback. It will also be set to true when permanent is true.
When the event is triggered and none of them are set to true, you should resume the track.
But maybe I am misunderstanding how remote-duck should work. If someone can offer insight on why I am supposed to call stop when remote-duck's permanent parameter is true I would appreciate it. In any case I'll close this issue now.
When the OS says that the user won't use your player any longer, you should release it's resources.
stop() does that, and it also removes the notification and anything that the user might expect to go away when they start playing "permanent" audio in another app.
It's just a good practice in both performance and user experience.
I have also noticed same bahaviour today.
iOS triggers remote-duck with permanent: true when the player app returns to foreground , but only in case the track was paused before app going to background.
How is that supposed to be telling the player that OS won't be using it as it comes back to foreground and was playing before?
Just ran into this today as well. Very unexpected behaviour. I now resorted to checking if the track is playing before making it stop or pause as a result of remote-duck.
Most helpful comment
I have also noticed same bahaviour today.
iOS triggers
remote-duckwithpermanent: truewhen the player app returns to foreground , but only in case the track was paused before app going to background.How is that supposed to be telling the player that OS won't be using it as it comes back to foreground and was playing before?