Start position of 0 always resolves to default position for live playbacks

[REQUIRED] Searched documentation and issues

Since the problem only appeared after updating from 2.11.8 to 2.12.0 I searched the recent issues for “seek” and “startPosition” but didn’t find anything that seemed related.

[REQUIRED] Question

In our TV app we offer users the possibility to watch the current program from the beginning, i. e. instead of simple live stream with a short live window we have a stream with a fixed start but which grows in length every time a new segment is available on the streaming server.

Since the default position in those streams seems to be right at the live edge we have always passed the start position (simpleExoPlayer.seekTo(0)) explicitly before prepare()ing the player. Up until and including 2.11.8 this has worked without any problems.

Since updating to 2.12.0 a few days ago this “initial seek position” seems to be ignored and the player starts at the default position, at the live edge. I saw that the prepare(mediaSource, false, true) which we were using so far is now deprecated. But replacing it with

simpleExoPlayer.setMediaSource(buildMediaSource(), startPositionInMs)
simpleExoPlayer.prepare()

does not resolve the problem. Even here, it seems that the startPositionInMs is ignored.

Unfortunately, I cannot provide a public test stream to demonstrate the problem, but this is the HLS master playlist:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=1963735,PROGRAM-ID=1,CODECS="avc1.4d4028,mp4a.40.2",RESOLUTION=960x540
04(start=1600850100_stop=1600864500).m3u8
#EXT-X-STREAM-INF:BANDWIDTH=4636146,PROGRAM-ID=1,CODECS="avc1.4d4028,mp4a.40.2",RESOLUTION=1280x720
01(start=1600850100_stop=1600864500).m3u8
#EXT-X-STREAM-INF:BANDWIDTH=3055720,PROGRAM-ID=1,CODECS="avc1.4d4028,mp4a.40.2",RESOLUTION=1280x720
02(start=1600850100_stop=1600864500).m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2340502,PROGRAM-ID=1,CODECS="avc1.4d4028,mp4a.40.2",RESOLUTION=1280x720
03(start=1600850100_stop=1600864500).m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1146343,PROGRAM-ID=1,CODECS="avc1.4d401e,mp4a.40.2",RESOLUTION=640x360
05(start=1600850100_stop=1600864500).m3u8
#EXT-X-STREAM-INF:BANDWIDTH=686561,PROGRAM-ID=1,CODECS="avc1.4d401e,mp4a.40.2",RESOLUTION=480x270
06(start=1600850100_stop=1600864500).m3u8
#EXT-X-STREAM-INF:BANDWIDTH=185753,PROGRAM-ID=1,CODECS="avc1.4d400d,mp4a.40.2",RESOLUTION=320x180
07(start=1600850100_stop=1600864500).m3u8

and this is the start of one of the variant playlists:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-PLAYLIST-TYPE:EVENT
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:400212523
#EXT-X-PROGRAM-DATE-TIME:2020-09-23T08:35:03Z
#EXTINF:4, no desc
20200814T123515-01-400212523.ts
#EXT-X-PROGRAM-DATE-TIME:2020-09-23T08:35:07Z
#EXTINF:4, no desc
20200814T123515-01-400212524.ts
#EXT-X-PROGRAM-DATE-TIME:2020-09-23T08:35:11Z
#EXTINF:4, no desc
20200814T123515-01-400212525.ts
#EXT-X-PROGRAM-DATE-TIME:2020-09-23T08:35:15Z
#EXTINF:4, no desc
20200814T123515-01-400212526.ts
#EXT-X-PROGRAM-DATE-TIME:2020-09-23T08:35:19Z
#EXTINF:4, no desc
20200814T123515-01-400212527.ts
#EXT-X-PROGRAM-DATE-TIME:2020-09-23T08:35:23Z
#EXTINF:4, no desc
20200814T123515-01-400212528.ts
#EXT-X-PROGRAM-DATE-TIME:2020-09-23T08:35:27Z
#EXTINF:4, no desc
20200814T123515-01-400212529.ts
#EXT-X-PROGRAM-DATE-TIME:2020-09-23T08:35:31Z
#EXTINF:4, no desc
20200814T123515-01-400212530.ts
...

As I said, the variant playlists grow for three more lines every four seconds, when the next segment becomes available.

It may well be a configuration issue with our streams (this time, for once, the newly configured DASH streams work better for the same scenario, but we cannot migrate all streams from HLS to DASH at the moment) - but since it still worked with 2.11.8 I thought there might be a way to get it to work with 2.12.0.

[stevemayhew]

@marcbaechinger exactly… I’ve started on a test case in ExoPlayerTest to prove this, great to have this framework now since code in ExoPlayerImplInternal is pretty tough to test.

My thought from there was to look at enforcing these states for defaultPositionUs

1. C.TIME_UNSET - no default has been set (the placeholder should have this unless an initial seek is done)
2. 0 - durationUs - valid initial starting position

Some logic (ClippingMediaSource) checks for this already, others (notably MaskingMediaSource) do not. I get the general idea of ad insertion and timelines, but you all are in the thick of it more 😉

Let me know if the test case would be welcome with a pull request, otherwise I have plenty to work on 😉 The seek to 1 is dirty, but it “works”

[stevemayhew]

Exactly, the seekTo(1) is fine for us. I agree with your suggestion for the fix, looked more involved then I wanted to attempt in a pull request