react-native-track-player: [iOS/Android] Bugs or strange behavior
Hi, I am currently using the version 1.1.2 of the library and once again that’s an amazing job you are doing there. Here are some strange things I am experimenting with this version :
Configuration
package.json
"react": "16.3.1",
"react-native": "0.55.4",
"react-native-track-player": "^1.1.2",
"react-native-swift": "^1.2.2",
react-native info
Environment:
OS: macOS High Sierra 10.13.6
Node: 8.11.2
Yarn: 1.9.4
npm: 5.6.0
Watchman: 4.9.0
Xcode: Xcode 10.1 Build version 10B61
Android Studio: 3.2 AI-181.5540.7.32.5056338
Packages: (wanted => installed)
react: 16.3.1 => 16.3.1
react-native: 0.55.4 => 0.55.4
iOS
- Jump forward / Jump backward / Stop
I am initialising my player like follow :
static async initPlayer() {
await TrackPlayer.setupPlayer().then(() => console.log('created'));
TrackPlayer.updateOptions({
stopWithApp: true,
jumpInterval: 60,
capabilities: [
TrackPlayer.CAPABILITY_PLAY,
TrackPlayer.CAPABILITY_PAUSE,
TrackPlayer.CAPABILITY_STOP,
TrackPlayer.CAPABILITY_SEEK_TO,
TrackPlayer.CAPABILITY_JUMP_FORWARD,
TrackPlayer.CAPABILITY_JUMP_BACKWARD,
],
});
}
But for this configuration I happened to have all of this results (I still think the output changes considering when I open the media center, if I open it very fast before/during the track adding it usually bugs and give me a missing side or both side missing). Moreover now you can also see that the stop button never appears (but it does on Android).
Normal output (with the old version cause I never got this with the new version):

Left missing :

Both missing : (most of the time I get this one)

- Infinite Loop event
That’s maybe not a bug but still wanna talk about it just in case :
Creating the service.js this way, with an empty queue of file to play you will get the ‘playback-queue-ended’ event in an infinite loop :
import TrackPlayer from 'react-native-track-player';
module.exports = async function service() {
// ...
TrackPlayer.addEventListener('remote-stop', () => {
TrackPlayer.destroy();
});
TrackPlayer.addEventListener('playback-queue-ended', (infos) => {
TrackPlayer.reset();
});
};
Android
- Seek bar not available in notification :
For this I don’t know if it can be considered a bug or if it was just not wanted, but there are no seek bar available in the notification (in opposite of iOS).
- Restart playing automatically on end :
When the player finish to read the current track for some reason it auto restart to play the same track. (on iOS with the same code the track just doesn’t restart which is normal)
- Jump forward / Jump backward is not linked to JumpInterval option :
Supposedly JumpInterval is "The interval in seconds for the jump forward/backward buttons " But in the documentation it is also written (https://github.com/react-native-kit/react-native-track-player/wiki/Documentation#remote-jump-forward) that the event will give “usually” the time given in the option. In my case, on Android the time Interval given to the event is always 15 instead of the 60 defined in the options (on iOS the JumpInterval works nicely with the 60).
Thanks a lot for this amazing library and I hope it helps 👍 Best regards
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 22 (13 by maintainers)
It seems
ExoPlayer’sonPlayerStateChangedmethod is getting called twice when setting up the player, first time with Player’s state = STATE_NONE, second time STATE_STOPPED, which sendsplayback-queue-endedevent. In case youTrackPlayer.reset()in the listener, it results in the infinite loop. @Guichaguri I’m thinking about what the solution could be like, wouldn’t it be enough to check thepreviousState!=STATE_NONEin theonPlayerStateChangedinstead of justif(state == PlaybackStateCompat.STATE_STOPPED) { manager.onEnd(getCurrentTrack(), getPosition()); }?@ithustle this issue was already discussed in #451.
I used to use that library a few months ago, but I decided to switch to ExoPlayer’s cache since it works pretty well with any type of stream.
Please, open new issues for each topic you want to discuss, this issue is for another problem and it’s getting too off topic.
That’s how each platform deals with states. There’s nothing to worry about, since you can safely check for each state using the constants:
state === TrackPlayer.STATE_PLAYING