ExoPlayer 2.2.0 stops downloading media segments of HLS stream

[mcart666]

Issue description

Playback of live HLS streams freezes because the player doesn't download subsequent media segments specified by HLS playlist. In this case player enters BUFFERING state that never ends. Only restart of player helps. By "live HLS" I mean streams where m3u8 playlists are periodically updated.

When I observe calling onLoadStarted/onLoadCompleted methods (inherited from AdaptiveMediaSourceEventListener) I can see that after freeze, onLoadCompleted is run only for m3u8 playlists. There are no GET requests for media segments - checked in server log and network traffic dumped with wireshark. Playlist contains correct information about media segments that should be played next (see attached sample stream).

Issue can be reproduced on ExoPlayer demo application. Reproduction rate: 100%.

Reproduction steps

1. Please download the dumped piece of HLS stream (link in "Link to test content" section).

2. Serve the stream using your local apache:
   cd /var/www/html
   tar -zxvf linear-hang-20170315.tar.gz

3. Modify "media.exolist.json" in ExoPlayer demo by adding the new stream in HLS section, for example:
   {
   "name": "Playback freeze example",
   "uri": "http://<ip:port of your apache>/linear-hang/RAVE-HIST-HD/RAVE-HIST-HD.m3u8"
   }

4. Launch the demo and select the stream defined in previous step.

5. As soon as playback is started, immediately update the playlist:
   cd /var/www/html/linear-hang/RAVE-HIST-HD/
   cp 01.m3u8-next 01.m3u8

The purpose of this step is to force extending the playlist which simulates live HLS stream. If you wish to repeat the test you'll need to revert the playlist to initial form:
cp 01.m3u8-initial 01.m3u8

6. Wait about 7 minutes until playback freezes. It happens always after downloading media segment 38419 (if playback starts from segment 38372).

Additional information:

1. When you modify the initial playlist by adding one more entry, playback starts on segment 38373 and freezes on 38420.
2. You won't be able to reproduce the issue with provided media sample when different than the default sizes of memory buffers are used. Normally the instance of DefaultLoadControl is created with "minBufferMs = 15000" and "maxBufferMs = 30000". When both limits are set to bigger values, i.e. 360000 ms, playback correctly proceeds after segment 38419. However please don't consider it as the solution - freezes still occur in our production environment despite the fact that different buffer sizes are used.

Link to test content

Archive containing dump of live HLS stream "linear-hang-20170315.tar.gz":
https://drive.google.com/file/d/0B6QARQwh4JXGMHRSdllXQlZsaWc/view

Version of ExoPlayer being used

ExoPlayer 2.2.0 (the latest version at the moment the issue is posted).

Device(s) and version(s) of Android being used

Xiaomi MIBOX3 - Android TV v6.0.1

A full bug report captured from the device

There are no errors reported.

[AquilesCanta]

This is a duplicate of #2233. Have a look there. The short answer is that every chunk declares a higher duration than it actually contains (actual duration ~10.6, declared duration 11). This gets accumulated after some time, which means that ExoPlayer think it has buffered more than the loaded chunks actually contain.

We might do something about this in the near future, but the best solution is to update the playlists to a more recent HLS version.