Prevent wrong value from getTotalBufferedDurationUs

[fgl27]

prevent negative value for rendererPositionUs, in random cases
for a split second the value of rendererPositionUs is negative
after a seekto or starting a playback with a ResumePosition >>> 0
for example, what results on a wrong and too big value be returned

Signed-off-by: fgl27 fglfgl27@gmail.com

[andrewlewis]

@tonihei @marcbaechinger Please could you take a look?

[tonihei]

The rendererPosition shouldn't be negative really. If you can reproduce the problem, can you open a new GitHub issue instead with reproduction steps? It feels we should fix the underlying issue instead of working around it. I'll close this PR for now assuming we won't need it, but feel free to reopen.

[fgl27]

You guys now about the issue so fell free to fix the way you like I will not open a issue as I already fix on my side, and yes is better to fix where this start but I don't know where it is, I fix here because is simple and works, I have very limit time to work on my projects, so you guys fix this the way you prefere.

I log the values from the function and start to seekto after a few tries I get the issue.

https://github.com/fgl27/ExoPlayer/blob/0252b1582c79122e3ca1725f0a7d00734b9223ad/library/core/src/main/java/com/google/android/exoplayer2/ExoPlayerImplInternal.java#L2105

Log it individual totalBufferedDurationUs, bufferedPositionInLoadingPeriodUs, loadingPeriodHolder.toPeriodTime(rendererPositionUs) and rendererPositionUs

During the test I notice that when the problem happens was because rendererPositionUs was negative.

I only notice it because I added a progress bar that shows the buffered size in the progress bar, after a seekto or when the app resumes I notice that the buffer part was too big.

That red part on the bar next to the circle is the buffer, it also show on top right corner in seconds, but I really notice on the bar.

[tonihei]

I can't reproduce that (even with logging). Note that there is an edge case in which the renderer may report a position that is slightly more than the buffered position. We have a guard against that (5 lines further down from your change) that effectively prevents any buffered position to become negative. If you see this happening again and you think there is a bug, please file an issue with reproduction steps because there is nothing I can do without knowing further details.

[fgl27]

I can

darcy:/ $ logcat | grep BUFFER_TEST                                                                                    
06-01 11:08:12.593  1979  2227 W BUFFER_TEST: rendererPositionUs -25776

fgl27@6601c64

seeking on a hls vod, did a seek 4, 5 times and one did result in negative.

[tonihei]

Thanks. I was now able to see it too on the HLS TS media playlist in our demo app. Looks like something is going wrong with the audio timestamp tracking.

@andrewlewis Could you have a look if that's an issue we should look into or provide a workaround?

• AudioTrackPositionTracker returns a position based on the "smoothedPlayheadOffsetUs" that is less than "latencyUs", so the resulting renderer position is negative. (I my debug example this was 40940-108023=-67083 right the start of playback). This happens occasionally after a position reset including seeks and at the beginning of playback.

[ojw28]

@andrewlewis - I can take a look at this if you like.

[tonihei]

I'll moved it to a new issue because this one is a closed PR (see #7456).