HLS Playlist with PlaylistType=Event cannot be loaded properly

[dmytropiriatenets]

Preconditions

To reproduce the issue it's required to have the .m3u8 master playlist with a list of several media playlist (i.e., one of them is for subtitles, all others are to cover different bandwidth).
Further by service I mean the one which prepares the playlist by request, and which ExoPlayer communicates directly with

Description

The issue happens with the HLS playlist which has PlaylistType=Event (EXT-X-PLAYLIST-TYPE:EVENT). The specific of such a playlist in the service implementation is that when it's requested first time from the service, the service returns partial playlist, which doens't have the EndTag (EXT-X-ENDLIST). Depending on the service load, after the second request the service might return either the full stream (which has EXT-X-ENDLIST), or another partial playlist but with more data, and this will continue till the list with EXT-X-ENDLIST tag received. [let's further call such playlists as HLS Event Stream [playlists]].

Since it's HLS Event Stream, the data could be appended to the end of the playlist (according to https://datatracker.ietf.org/doc/html/rfc8216)

Issue

When the playback of such a playlist starts, ExoPlayer cannot receive the full playlist and therefore, cannot get required metadata (like duration etc).
When the playback starts, the ExoPlayer starts loading different media playlist from the master playlist, and even though the loading happens properly (according to Web debugging proxy tool), the received data is not delivered properly inside the ExoPlayer framework.

Investigation

While investigating the ExoPlayer framework (using the ExoPlayer Demo app of the version 2.14.1), the code which causes the described behaviour was found in the DefaultHlsPlaylistTracker.
The following happens: different playlist are downloaded, the method processLoadedPlaylist is called, which calls onPlaylistUpdated (as expected). But inside the onPlaylistUpdated there's a check if (url.equals(primaryMediaPlaylistUrl)) which is false all the time. After some debugging, it turned out that HlsChunkSource calls getPlaylistSnapshot, this one calls maybeSetPrimaryUrl method, which might override the primaryMediaPlaylistUrl value (which basically happens always).
The method maybeSetPrimaryUrl is called many times, but it always called right after onPlaylistUpdated for the same url, which makes the if condition be false almost all the time (because primaryMediaPlaylistUrl remains the same after the previous maybeSetPrimaryUrl call).
(attaching some logs showing this behaviour)

Because of not calling primaryPlaylistListener.onPrimaryPlaylistRefreshed(newSnapshot); (which is inside the if check), the SinglePeriodTimeline couldn't be created inside the HlsMediaSource::onPrimaryPlaylistRefreshed, which is a single place to create the timeline for Hls Playlist.

After creating the own implementation of DefaultHlsPlaylistTracker and removing the if (url.equals(primaryMediaPlaylistUrl)) check, the issue dissappeared, however, it couldn't be considered as a proper fix (unless you could confirm that it is).

Thanks in advance

Additional info

• ExoPlayer version number: 2.14.1 (could be reproduced on earlier versions, like 2.12.1)
• Android version: API 28 (could be reproduced on other versions as well)
• Android device: (Android Emulator API 28, Xiaomi Mi Box, Google Pixel 2 XL)

[ojw28]

Thanks for the detailed report! We've been provided with another bug report that looks similar to this one, and can be fixed in the same way (although I don't think that's quite the right fix). It's hard to be completely certain that both issues are exactly the same, since you haven't provided a test stream for us to check with, but we can probably work under the assumption that they are. I'll update this issue when the fix is in dev-v2. Once that happens, it would be great if you could verify that the issue is fixed on your side.

[ojw28]

Closing on the assumption that the commit above fixes the issue, but please check and let us know if this is not the case. Thanks!

[dmytropiriatenets]

Thanks @ojw28 , I'll try the fix as soon as possible and update you with the result!

[dmytropiriatenets]

I've did some checks on top of 2.14.1, this solution works fine.
In our product we still use ExoPlayer v2.12.1 (since we have the dependency on Amazon, which just recently updated to v2.13.3, and weren't able to migrate to it yet).
So, I've added similar fix to the DefaultHlsPlaylistTracker (as some method differs from 2.14.1 version)

        MediaPlaylistBundle newPrimaryBundle = playlistBundles.get(primaryMediaPlaylistUrl);
        @Nullable HlsMediaPlaylist newPrimarySnapshot = newPrimaryBundle.playlistSnapshot;
        if (newPrimarySnapshot != null && newPrimarySnapshot.hasEndTag) {
            primaryMediaPlaylistSnapshot = newPrimarySnapshot;
            primaryPlaylistListener.onPrimaryPlaylistRefreshed(newPrimarySnapshot);
        } else {
            // The snapshot for the new primary media playlist URL may be stale. Defer updating the
            // primary snapshot until after we've refreshed it.
            newPrimaryBundle.loadPlaylist();
        }

and it also worked fine in the application.
Thanks @ojw28 for such a quick and tiny yet so important fix for the issue.