React-native-track-player: Track player pauses after calling seekTo on a large audio file

[nishanBende]

Configuration

react-native-track player version - 1.1.8

System:
OS: macOS Mojave 10.14.6
CPU: (4) x64 Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz
Memory: 22.71 MB / 8.00 GB
Shell: 5.3 - /bin/zsh
Binaries:
Node: 10.16.0 - ~/.nvm/versions/node/v10.16.0/bin/node
Yarn: 1.16.0 - ~/.nvm/versions/node/v10.16.0/bin/yarn
npm: 6.9.0 - ~/.nvm/versions/node/v10.16.0/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.2, macOS 10.14, tvOS 12.2, watchOS 5.2
IDEs:
Xcode: 10.2.1/10E1001 - /usr/bin/xcodebuild
npmPackages:
react: 16.9.0 => 16.9.0
react-native: 0.61.1 => 0.61.1
npmGlobalPackages:
react-native-cli: 2.0.1
react-native: 0.59.4

Issue

Platform: IOS I havent tested it for android yet.
Track player pauses after calling seekTo on a large audio file. I tried it with a 3hr long audio.

Code

Reproducible repo link: https://github.com/nishanBende/react-native-track-player-seekTo-issue/blob/master/App.js#L13

let track = {
    url: 'http://traffic.libsyn.com/joeroganexp/p1355.mp3',
    id: '1',
    title: 'abc',
    artist: 'abc',
};

await TrackPlayer.add(track);
await TrackPlayer.play();
const oldPosition = await TrackPlayer.getPosition();

TrackPlayer.addEventListener('playback-state', async data => {
    console.log('state ', data);

        if (data.state === 'ready') {
            await TrackPlayer.seekTo(5030);
            await TrackPlayer.seekTo(6000);
            const newPosition = await TrackPlayer.getPosition();
            console.log('positions ', oldPosition, newPosition);
        }
});

Logs:

state  {state: "loading"}
state  {state: "ready"}
state  {state: "playing"}
positions  0 6000
state  {state: "paused"}

The track player goes into a pause state.
It happens in-frequently, but it is easily reproducible.

[nishanBende]

I noticed in Xcode I get the below log when this happens

Seeking to 4100.0 seconds
2019-09-27 08:27:01.739192+0530 trackplayer[36849:421118] Task <11FC1088-A5A7-4DDB-BD34-164217A1BDF9>.<7> load failed with error Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo={NSErrorFailingURLStringKey=http://hwcdn.libsyn.com/p/4/b/3/4b3a79cd96dce263/p1355.mp3?c_id=52646822&cs_id=52646822&expiration=1569569877&hwt=d3d0ffe4f792831d999a3f82bd51adfa, NSErrorFailingURLKey=http://hwcdn.libsyn.com/p/4/b/3/4b3a79cd96dce263/p1355.mp3?c_id=52646822&cs_id=52646822&expiration=1569569877&hwt=d3d0ffe4f792831d999a3f82bd51adfa, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "LocalDataTask <11FC1088-A5A7-4DDB-BD34-164217A1BDF9>.<7>"
), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <11FC1088-A5A7-4DDB-BD34-164217A1BDF9>.<7>, NSLocalizedDescription=cancelled} [-999]
2019-09-27 08:27:01.754573+0530 trackplayer[36849:421048] Task <11FC1088-A5A7-4DDB-BD34-164217A1BDF9>.<7> finished with error - code: -999
2019-09-27 08:27:02.274150+0530 trackplayer[36849:421615] [Symptoms] {
  "transportType" : "HTTP Progressive Download",
  "mediaType" : "HTTP Progressive Download",
  "BundleID" : "trackplayer",
  "name" : "MEDIA_PLAYBACK_STALL",
  "interfaceType" : "Wifi"
}

[Sathyanarayan09]

Same issue for me with iOS, I tested this on Android were the state is changing to buffering on seek and later after downloading player resumes, This should be iOS specific bug.

[Sathyanarayan09]

@nishanBende after few workaround I got the solution -> Don't round or do any Math on the position you're seeking to, just pass the whole value which is coming from progress using useReackPlayerProgress()

[nishanBende]

@Sathyanarayan09 can you please explain in detail?
I have a progress slider and if the user slides it, I get those values and i am just passing it to seekTo and then it pauses sometimes.

[sslash]

I also have this issue, some times it happens even if I don't seek. On large files (e.g podcasts) in particular

[sslash]

I noticed in Xcode I get the below log when this happens

Seeking to 4100.0 seconds
2019-09-27 08:27:01.739192+0530 trackplayer[36849:421118] Task <11FC1088-A5A7-4DDB-BD34-164217A1BDF9>.<7> load failed with error Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo={NSErrorFailingURLStringKey=http://hwcdn.libsyn.com/p/4/b/3/4b3a79cd96dce263/p1355.mp3?c_id=52646822&cs_id=52646822&expiration=1569569877&hwt=d3d0ffe4f792831d999a3f82bd51adfa, NSErrorFailingURLKey=http://hwcdn.libsyn.com/p/4/b/3/4b3a79cd96dce263/p1355.mp3?c_id=52646822&cs_id=52646822&expiration=1569569877&hwt=d3d0ffe4f792831d999a3f82bd51adfa, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "LocalDataTask <11FC1088-A5A7-4DDB-BD34-164217A1BDF9>.<7>"
), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <11FC1088-A5A7-4DDB-BD34-164217A1BDF9>.<7>, NSLocalizedDescription=cancelled} [-999]
2019-09-27 08:27:01.754573+0530 trackplayer[36849:421048] Task <11FC1088-A5A7-4DDB-BD34-164217A1BDF9>.<7> finished with error - code: -999
2019-09-27 08:27:02.274150+0530 trackplayer[36849:421615] [Symptoms] {
  "transportType" : "HTTP Progressive Download",
  "mediaType" : "HTTP Progressive Download",
  "BundleID" : "trackplayer",
  "name" : "MEDIA_PLAYBACK_STALL",
  "interfaceType" : "Wifi"
}

I get the same error, but I also get this one before that:

2019-10-10 07:03:02.615102+0200 lift[7620:293738] Task <A0DEA8F4-97DC-494A-AE45-21D5D93484FD>.<2> load failed with error Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo={NSErrorFailingURLStringKey=https://traffic.libsyn.com/secure/mindpump/1132_How_to_Build_Your_Triceps.mp3?dest-id=248504, NSErrorFailingURLKey=https://traffic.libsyn.com/secure/mindpump/1132_How_to_Build_Your_Triceps.mp3?dest-id=248504, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "LocalDataTask <A0DEA8F4-97DC-494A-AE45-21D5D93484FD>.<2>"
), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <A0DEA8F4-97DC-494A-AE45-21D5D93484FD>.<2>, NSLocalizedDescription=cancelled} [-999]

[alburdette619]

This happens for me just loading hls audio the first time. The status goes `idle => ready => loading => paused". If I then "pause" and play again everything is fine.

[alburdette619]

I found my issue here and I fixed it with an undocumented config prop used in setupPlayer: waitForBuffer. This sets the AVPlayer prop automaticallyWaitsToMinimizeStalling, which the library is setting to false by default. This is necessary apparently for HLS.

[joaoschaab]

same issue here +1