Failed to receive STATE_END after calling seekTo() to seek to end of video

[ptran-gpfw]

We are implementing a kind of loop feature where if the position is at end of video then user can tap play button and position is restored to 0 and playback re-starts from beginning.

However, there is an issue when we call seekTo( durationMs ) where durationMs is the video duration retrieved from ExoPlayer#getDuration(). After this call to seekTo we rarely get the onPlayerStateChanged callback from ExoPlayer. We expect to receive an event for STATE_END.

We only observe the event for STATE_BUFFERING but rarely get the STATE_END event. Rarely meaning 1 out of 10 times we get the expected STATE_END event.

This is an issue for use because we need the STATE_END event to let us know we are at the end at should loop and restart playback from beginning.

Another datapoint: we have a workaround where 1 millisecond is subtracted from the seekTo value. I.e.,

seekTo( durationMs - 1)

This workaround is allows us to get expected STATE_ENDED event 100% of the time.

(CC: @FranciscoRuiz-gpsw)

[ptran-gpfw]

Related (kind of) to #490.

[ojw28]

What components are you using to build your player? Specifically, which SampleSource implementation are you using?

[ptran-gpfw]

ExtractorSampleSource with Mp4Extractor:

    private static final int BUFFER_SIZE = 10 * 1024 * 1024;

        String userAgent = Util.getUserAgent(context, GPHttpUtil.getHeaderUserAgent(context));
        DataSource dataSource = new DefaultUriDataSource(context, userAgent);
        mSampleSource = new ExtractorSampleSource(uri, dataSource, new Mp4Extractor(), 2,
                BUFFER_SIZE);

[andrewlewis]

I'm investigating an issue where seeking to the end of a stream with ExtractorSampleSource can cause the player to get stuck without transitioning to STATE_ENDED. The extractor immediately signals that the end of the stream has been reached, but the last buffer from the audio decoder contains media that is never played, so the player never sees the end of the stream. This may be specific to MP3.

[brianchu]

It also happens to HLS when the video is actually shorter (or longer) or the m3u file doesn't have TARGETDURATION

[ojw28]

This should be fixed on dev.