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): capture d ecran 2018-10-24 a 17 17 58

Left missing : capture d ecran 2019-02-14 a 14 26 58

Both missing : (most of the time I get this one) capture d ecran 2019-02-14 a 13 54 31

  • 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)

Most upvoted comments

It seems ExoPlayer’s onPlayerStateChanged method is getting called twice when setting up the player, first time with Player’s state = STATE_NONE, second time STATE_STOPPED, which sends playback-queue-ended event. In case you TrackPlayer.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 the previousState!=STATE_NONE in the onPlayerStateChanged instead of just if(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