TrackPlayer.seekTo resets the track

[Alluisio]

Describe the Bug When using seekTo the track restarts and starts from position 0, my duration is 0, both in useProgress and getProgress, even putting the value when adding the track

In my setupPlayer I have:

try {
      const audioUrl = 'xxxxx';


      await TrackPlayer.add({
        url: audioUrl,

        album: "",
        contentType: "audio/mpeg",
        duration: timeToSeconds(episodeDuration),
        id: episodeUuid,
        podcastId: podcastName,
        podcastTitle: podcastName,
        title: episodeName,
        isLiveStream: true,
        type: TrackType.SmoothStreaming,
      });

      await TrackPlayer.updateOptions({
        android: {
          appKilledPlaybackBehavior: AppKilledPlaybackBehavior.StopPlaybackAndRemoveNotification,
        },
        capabilities: [
          Capability.Play,
          Capability.Pause,
          Capability.SkipToNext,
          Capability.SkipToPrevious,
          Capability.Stop,
          Capability.SeekTo,
        ],
        compactCapabilities: [Capability.Play, Capability.Pause],
        notificationCapabilities: [Capability.Play, Capability.Pause, Capability.SeekTo],
      });

      await TrackPlayer.play();
    } catch (error) {
      console.log(error);
    }

service.js:

import TrackPlayer, { Event } from "react-native-track-player";

module.exports = async function () {
  TrackPlayer.addEventListener(Event.RemotePlay, () => TrackPlayer.play());
  TrackPlayer.addEventListener(Event.RemotePause, () => TrackPlayer.pause());
  TrackPlayer.addEventListener(Event.RemoteSeek, (position) => TrackPlayer.seekTo(position));
};

Environment Info: Paste the results of npx react-native info

System:
  OS: Windows 10 10.0.22631
  CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
  Memory: 2.18 GB / 15.73 GB
Binaries:
  Node:
    version: 18.19.0
    path: C:\Program Files\nodejs\node.EXE
  Yarn:
    version: 1.22.21
    path: C:\Program Files\nodejs\yarn.CMD
  npm:
    version: 10.2.3
    path: C:\Program Files\nodejs\npm.CMD
  Watchman: Not Found
SDKs:
  Android SDK: Not Found
  Windows SDK: Not Found
IDEs:
  Android Studio: Not Found
  Visual Studio: Not Found
Languages:
  Java:
    version: 11.0.22
    path: C:\Program Files\Eclipse Adoptium\jdk-11.0.22.7-hotspot\bin\javac.EXE
  Ruby: Not Found
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.72.10
    wanted: 0.72.10
  react-native-windows: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found

Paste the exact react-native-track-player version you are using "react-native-track-player": "^4.0.1", Real device? Or simulator? Simulator and on device What OS are you running? Android

I can't provide the audio because it's restricted, but if you provide me with a test audio I can implement it and check if the error still happens

[Alluisio]

I implemented

TrackPlayer.addEventListener(Event.PlaybackState, (event) => {
    console.log("Event.PlaybackState", event);
  });

in service.js, to check if the track status changed, I get the following return when using seekTo

 LOG  Event.PlaybackState {"state": "buffering"}
 LOG  Event.PlaybackState {"state": "ready"}
 LOG  Event.PlaybackState {"state": "playing"}

wait about 2 seconds in 'buffering' and continue

[Alluisio]

when using implementation with local file it works correctly, however, when using the api to return the track, it restarts

  async function addTrackAndPlay() {
    await PlaybackService();
    TrackPlayer.updateOptions({
      android: {
        appKilledPlaybackBehavior:
          AppKilledPlaybackBehavior.StopPlaybackAndRemoveNotification,
      },
      capabilities: [
        Capability.Play,
        Capability.Pause,
        Capability.SkipToNext,
        Capability.SkipToPrevious,
        Capability.Stop,
        Capability.SeekTo,
      ],
      compactCapabilities: [Capability.Play, Capability.Pause],
      notificationCapabilities: [
        Capability.Play,
        Capability.Pause,
        Capability.SeekTo,
      ],
    });

    await TrackPlayer.add({
      url: require("./audio.mp3"),
      title,
      artist,
      album: "",
      artwork:
        "https://polodigitaldemanaus.com/wordpress/wp-content/uploads/2021/04/Frame-2apdm-ipdec.png",
    });

    await TrackPlayer.play();
  }

it works

[lovegaoshi]

very likely is your media source... see example https://github.com/doublesymmetry/react-native-track-player/blob/main/example/src/assets/data/playlist.json

[Alluisio]

first item: duration ok, position ok, seek to ok second item: duration ok, position ok, seek to ok third item: duration ok, position ok, seek to ok fourth item: duration ok, position ok, seek to ok fifth item: duration ok, position ok, seek to ok (TrackType.HLS) sixth item: duration 0, position ok, seek to restart the track (isLiveStream: true) seventh item: duration ok, position ok, seek to ok sixth item: duration 0, position ok, seek to restart the track

[Alluisio]

very likely is your media source... see example https://github.com/doublesymmetry/react-native-track-player/blob/main/example/src/assets/data/playlist.json

Currently, I solved it by downloading the audio data completely, and then playing it, doing it this way I have the duration and the seek to works correctly

[mauricewijnia]

I'm also running into this problem. This only seems to happen on Android and when streaming from a chunked response. When the content length is known seeking works fine. Sadly downloading the data completely and then playing it is not an option for me, as the audio is being generated live on the server.

Anything we can do about this?

[lovegaoshi]

could u confirm this happens with a native app (eg in googles uamp) or not? then consult with the media3 team or check what their implementation does differently with rntp, depending on the outcome

On Tue, May 7, 2024, 7:34 AM Maurice Wijnia @.***> wrote:

I'm also running into this problem. This only seems to happen on Android and when streaming from a chunked response. When the content length is known seeking works fine. Sadly downloading the data completely and then playing it is not an option for me, as the audio is being generated live on the server.

Anything we can do about this?

— Reply to this email directly, view it on GitHub https://github.com/doublesymmetry/react-native-track-player/issues/2261#issuecomment-2098556293, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZMOVVV6235K5WDM5CH2YDLZBDRAZAVCNFSM6AAAAABD6SSNQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJYGU2TMMRZGM . You are receiving this because you commented.Message ID: @.*** com>

[mauricewijnia]

I tested the same audio stream in UAMP and indeed I was not able to seek forward or backward. However, the position does not reset.

However, when I make some small changes to the ExoPlayer initialization everything works as expected. The problem seems to be that ExoPlayer does not allow constant bitrate seeking when the content-length is not known, but iOS does allow this by default.

You can enable constant bitrate seeking in ExoPlayer, even when content-length is unknown like this:

        val factory = DefaultExtractorsFactory().setConstantBitrateSeekingAlwaysEnabled(true)

And then use that in the media source factory for the ExoPlayer instance:

        val player = ExoPlayer.Builder(this).setMediaSourceFactory(DefaultMediaSourceFactory(this, factory)).build().apply {
            setAudioAttributes(uAmpAudioAttributes, true)
            setHandleAudioBecomingNoisy(true)
            addListener(playerListener)
        }

I made these changes in the MusicService from the media3 branch: https://github.com/android/uamp/blob/ef5076bf4279adfccafa746c92da6ec86607f284/common/src/main/java/com/example/android/uamp/media/MusicService.kt#L141

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.