Audio only HLS stream stalls after first segment

[meh111]

Why player trying to reconnect to stream https://moondigitaledge2.radyotvonline.net/kafaradyo/playlist.m3u8 after every 3 seconds?
VLC player playing fine this stream.
codec: MPEG AAC Audio (mp4a)

version:
implementation 'com.google.android.exoplayer:exoplayer-core:2.14.0'
implementation 'com.google.android.exoplayer:exoplayer-hls:2.14.0'

Some strange log:
2021-07-06 02:01:13.409 8944-1381/com.aa.p I/ACodec: [] Now uninitialized
2021-07-06 02:01:13.413 8944-1398/com.aa.p I/ACodec: [] onAllocateComponent
2021-07-06 02:01:13.421 8944-1398/com.aa.p I/OMXClient: Treble IOmx obtained
2021-07-06 02:01:13.440 8944-1398/com.aa.p I/ACodec: [OMX.google.aac.decoder] Now Loaded
2021-07-06 02:01:13.445 8944-1398/com.aa.p I/ACodec: codec does not support config priority (err -2147483648)
2021-07-06 02:01:13.448 8944-1398/com.aa.p I/ACodec: [OMX.google.aac.decoder] Now Loaded->Idle
2021-07-06 02:01:13.468 8944-1398/com.aa.p I/ACodec: [OMX.google.aac.decoder] Now Idle->Executing
2021-07-06 02:01:13.473 8944-1398/com.aa.p I/ACodec: [OMX.google.aac.decoder] Now Executing
2021-07-06 02:01:13.481 8944-1398/com.aa.p I/ACodec: [OMX.google.aac.decoder] Now handling output port settings change

By the way another stream with the same format playing fine, for example https://stream.revma.ihrhls.com/zc849/hls.m3u8

[marcbaechinger]

It appears that the stream is a live stream. When you load the media playlist with for instance curl you can see that the media segments referenced by the playlist change and do not have an end tag. Reloading the playlist seems to be the correct behavior.

However, as you've observed the stream does not play with ExoPlayer. It stalls after having downloaded the first segment after playback starts. Thanks for providing the stream to the media. We look into this to see whether this is a problem on our side.

[AquilesCanta]

The problematic stream is missing the ID3 "com.apple.streaming.transportStreamTimestamp" metadata at the start. See HLS spec here. I think this was broken in 6f8a8fb.
I think you won't be affected by this issue if you change your dependency to 2.13.x (please try and post below letting us know) while we fix the issue at tip-of-tree.

I think we need to fix this, since this is a regression, even if the media is malformed.

Explanation of the issue: The new timestamp adjuster strategy will block the adjuster who tries to initialize the TimestampAdjuster with a different startTime than someone else who has started initialization with a different timestamp. In this case, the stream doesn't contain any adjustable timestamps because it's pure packed audio, and no ID3 TS timestamp leads the segments. So the extractor will be allowed to start initialization and finish extraction without adjusting any timestamps. When starting to extract the second segment, the same thread when reentering the timestamp adjuster will say that initialization has already started for a different first timestamp, so it will block the thread. Being the only thread that can initialize the timestamp, playback will never resume.

[AquilesCanta]

For ExoPlayer members' reference: I have published a fix for this specific issue in [internal ref: cl/383639556]. I don't think we should merge it because it will introduce a race condition where, if there are demuxed video and packed audio renditions, and the packed audio loader reaches the introduced timestamp adjustment branch before video, then the audio/video synchronization could be dramatically broken. Plus, this doesn't address the existence of a single empty segment at some point in a stream with a single rendition. I think the fix needs to be something more fundamental. We should probably discuss with @ojw28 next week, considering he authored the relevant change.

[AquilesCanta]

@ojw28 we need to revisit timestamp adjustment. Mind taking a look?