-
-
Notifications
You must be signed in to change notification settings - Fork 969
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TrackPlayer.seekTo resets the track #2261
Comments
I implemented
in service.js, to check if the track status changed, I get the following return when using seekTo
wait about 2 seconds in 'buffering' and continue |
when using implementation with local file it works correctly, however, when using the api to return the track, it restarts
it works |
very likely is your media source... |
first item: duration ok, position ok, seek to ok |
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 |
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? |
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
<#2261 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZMOVVV6235K5WDM5CH2YDLZBDRAZAVCNFSM6AAAAABD6SSNQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJYGU2TMMRZGM>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
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:
And then use that in the media source factory for the ExoPlayer instance:
I made these changes in the MusicService from the media3 branch: |
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:
service.js:
Environment Info:
Paste the results of
npx react-native info
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
The text was updated successfully, but these errors were encountered: