QueuedAudioPlayer currentTime and duration aren't reset immediately when jumping to a new item

[elliotdickison]

Describe the bug

QueuedAudioPlayer.currentTime and QueuedAudioPlayer.duration continue to return values for the previous item for a short time after loading a new item with QueuedAudioPlayer.jumpToItem. Interestingly enough I can reproduce on an iPhone SE Gen 1 (iOS 14.6) with some level of consistency but not at all on an iPhone XS (iOS 15.4.1), which suggests that this is either an incompatibility with older versions of iOS or is a race condition that's worse on lower-end devices (my guess).

To Reproduce

I am experiencing this bug in react-native-track-player, but followed the logic in RNTrackPlayer.swift back to this repo and am pretty sure the bug is in QueuedAudioPlayer. I'm not familiar with swift and can't provide a working example on that front, but at the risk of crossing the streams here is the gist of my react-native-track-player code:

await ReactNativeTrackPlayer.add([trackA, trackB])
await ReactNativeTrackPlayer.play()
// Wait a bit for track to load/play...
// Logs 0 + duration for trackA
console.log(await ReactNativeTrackPlayer.getCurrentTrack(), await ReactNativeTrackPlayer.getDuration())
await ReactNativeTrackPlayer.skip(1)
// Logs 1 + duration for trackA, even if I wait for the `PlaybackTrackChanged` event before calling this.
console.log(await ReactNativeTrackPlayer.getCurrentTrack(), await ReactNativeTrackPlayer.getDuration())
// Wait a bit for track to load/play...
// Logs 1 + duration for trackB
console.log(await ReactNativeTrackPlayer.getCurrentTrack(), await ReactNativeTrackPlayer.getDuration())

Expected behavior

I would expect currentTime and duration to reset to 0 immediately after calling jumpToItem, and eventually resolve to their actual values when the audio is loaded and/or playing.

Screenshots

N/A

Desktop (please complete the following information):

• OS: macOS
• Version 12.3

Smartphone (please complete the following information):
See Describe the bug above.

[puckey]

The reason for this is that in the current implementation the current item is only replaced after the new item has finished its initial load phase: https://github.com/doublesymmetry/SwiftAudioEx/blob/main/SwiftAudioEx/Classes/AVPlayerWrapper/AVPlayerWrapper.swift#L229

I am working on a pr that ought to address this issue: #28