HLS AVPlayerItem producing unknown error, -15419

We have an HLS playback system for some media, but recently we've started to see player item's logging an error:

Code Block
Player item error: -15419 CoreMediaErrorDomain The operation couldn’t be completed. (CoreMediaErrorDomain error -15419.) (null)


We're using 3 tracks; Media, Audio, and IFrame. It appears to happen when we're seeking. However, it appears the seek succeeds, we just don't know what is causing the error. I've looked at our Seekable and Loaded ranges and the seek times appear valid.

Our initial streaming playback seems to be starting a bit slower than normal, and we're afraid we have something inconsistent within our HLS playlists. Perhaps this error can indicate something?

Is it possible to find out what this error refers to?

Thanks
That error appears to indicate that there is a gap in the content.
Awesome thanks, that's kind of what we expect, well not the error. Our manifest contains some spaced out events and we're using gaps to ensure the program dates line up with the CMTime positions within the playlists (so we can seek smoothly, predictably, between events by a UTC to CMTime translation based on the HLS playlist start time).

Is there anything obvious that we could be doing to avoid the -15419 error? Additionally, we're seeing a significant performance degradation when playing playlists with GAPs like below vs our (same 6 hour ranged) streams that have data the entire way. Are there things we can do in this playlist that would improve our time to playback starting (first frame)? If GAPs are the problem, is there a way to know the valid UTC dates for segments within a playlist?

Our services had been returning multiple inits (#EXT-X-MAP tags) but that was killing our initial performance since they all appear to be fetched while the assets are loading, prior to allowing playback, etc.

Below is an example of our master, media, and audio HLS playlists (IFrame is similar), with the events spaced out. We don't request to play/seek during the GAPs, but it allows us to continuously seek between valid data events and have our seek's succeed. However, we've started to get the -15419 error recently, although everything seems to be working.

Master
Code Block
#EXT-X-STREAM-INF:BANDWIDTH=1000000,AUDIO="default-audio-group"
http://host/generateHlsMediaPlaylist?start_time=2021-05-12T11:41:58.161Z&end_time=2021-05-12T17:41:58.161Z&include_init_segment=true&type=MEDIA_TYPE_VIDEO&request_type=media_playlist
#EXT-X-MEDIA:GROUP-ID="default-audio-group",NAME="audio",TYPE=AUDIO,DEFAULT=YES,AUTOSELECT=YES,URI="http://host/generateHlsMediaPlaylist?start_time=2021-05-12T11:41:58.161Z&end_time=2021-05-12T17:41:58.161Z&include_init_segment=true&type=MEDIA_TYPE_AUDIO&request_type=audio_playlist"
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=125000,URI="http://host/generateHlsIFramePlaylist?start_time=2021-05-12T11:41:58.161Z&end_time=2021-05-12T17:41:58.161Z&include_init_segment=true&request_type=iframe_playlist"


Media
Code Block
#EXTM3U
#EXT-X-VERSION:8
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-TARGETDURATION:30
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PROGRAM-DATE-TIME:2021-05-12T14:15:27.504Z
#EXT-X-MAP:URI="http://host/fragments/0?request_type=media_segment",BYTERANGE="637@0"
#EXTINF:2.433,0.m4v
#EXT-X-BYTERANGE:645241@637
http://host/.../fragments/0?request_type=media_segment
#EXTINF:27.875,1.m4v
#EXT-X-BYTERANGE:6190168@637
http://host/.../fragments/1?request_type=media_segment
#EXT-X-GAP
#EXTINF:30,
missing.m4s
<...lots of 30s gaps...>
#EXT-X-GAP
#EXTINF:8.567,
missing.m4s
#EXT-X-DISCONTINUITY
#EXT-X-PROGRAM-DATE-TIME:2021-05-12T14:27:06.379Z
#EXTINF:17.627,0.m4v
#EXT-X-BYTERANGE:4263058@637
http://host/.../fragments/0?request_type=media_segment
#EXT-X-GAP
#EXTINF:30,
missing.m4s
<...lots of 30s gaps...>
#EXT-X-GAP
#EXTINF:2.679,
missing.m4s
#EXT-X-DISCONTINUITY
#EXT-X-PROGRAM-DATE-TIME:2021-05-12T14:29:26.685Z
#EXTINF:3.803,0.m4v
#EXT-X-BYTERANGE:904946@637
http://host/.../fragments/0?request_type=media_segment
#EXTINF:9.566,1.m4v
#EXT-X-BYTERANGE:2540650@637
http://host/.../fragments/1?request_type=media_segment
#EXT-X-GAP
#EXTINF:30,
missing.m4s
<...lots of 30s gaps...>
#EXT-X-GAP
#EXTINF:18.106999,
missing.m4s
#EXT-X-DISCONTINUITY
#EXT-X-PROGRAM-DATE-TIME:2021-05-12T14:41:58.161Z
#EXTINF:23.968,0.m4v
#EXT-X-BYTERANGE:6342949@637
http://host/.../fragments/0?request_type=media_segment
#EXT-X-ENDLIST


Audio
Code Block
#EXT-X-VERSION:8
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-TARGETDURATION:30
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PROGRAM-DATE-TIME:2021-05-12T14:15:27.226Z
#EXT-X-MAP:URI="http://host/.../fragments/0?include_segments=INIT_SEGMENT_ONLY&request_type=audio_segment"
#EXTINF:0.12,
http://host.../fragments/0?include_segments=MEDIA_SEGMENT_ONLY&request_type=audio_segment
#EXT-X-GAP
#EXTINF:0.313,
missing.m4s
#EXT-X-DISCONTINUITY
#EXT-X-PROGRAM-DATE-TIME:2021-05-12T14:15:27.659Z
#EXTINF:30.44,
http://host/.../fragments/1?include_segments=MEDIA_SEGMENT_ONLY&request_type=audio_segment
#EXT-X-GAP
#EXTINF:30,
missing.m4s
<...lots of 30s gaps...>
#EXT-X-GAP
#EXTINF:7.022,
missing.m4s
#EXT-X-DISCONTINUITY
#EXT-X-PROGRAM-DATE-TIME:2021-05-12T14:27:05.121Z
#EXTINF:18.84,
http://host/.../fragments/0?include_segments=MEDIA_SEGMENT_ONLY&request_type=audio_segment
#EXT-X-GAP
#EXTINF:30,
missing.m4s
<...lots of 30s gaps...>
#EXT-X-GAP
#EXTINF:2.727,
missing.m4s
#EXT-X-DISCONTINUITY
#EXT-X-PROGRAM-DATE-TIME:2021-05-12T14:29:26.688Z
#EXTINF:2.12,
http://host/.../fragments/0?include_segments=MEDIA_SEGMENT_ONLY&request_type=audio_segment
#EXTINF:11.2,
http://host/.../fragments/1?include_segments=MEDIA_SEGMENT_ONLY&request_type=audio_segment
#EXT-X-GAP
#EXTINF:30,
missing.m4s
<...lots of 30s gaps...>
#EXT-X-GAP
#EXTINF:18.139999,
missing.m4s
#EXT-X-DISCONTINUITY
#EXT-X-PROGRAM-DATE-TIME:2021-05-12T14:41:58.148Z
#EXTINF:23.96,
http://host/.../fragments/0?include_segments=MEDIA_SEGMENT_ONLY&request_type=audio_segment
#EXT-X-ENDLIST




I think you are using EXT-X-GAP incorrectly. The tip off in the spec is where it says

The client SHOULD NOT attempt to load Media Segments that have been marked with an EXT-X-GAP tag, or to load Partial Segments with a GAP=YES attribute. Instead, clients are encouraged to look for another Variant Stream of the same Rendition which does not have the same gap, and play that instead.

Gaps are intend to slide over temporary glitches on a single variant, not put empty space on all variants.

EXT-X-PROGRAM-DATE-TIME dates do not need to be adjacent. You can have arbitrary jumps, so long as no two points in the stream have the same date-time.

Yeah, I think that's the issue we were having. We were issues attempting to bridge those gaps and maintain program date time.

However, if we have jumps (i.e. use EXT-X-PROGRAM-DATE-TIME to skip the voids between data), how are we able to determine the CMTime for seeks based on program-date-time (UTC)? The only solution we've seen is to have a custom HLS parser to build up metadata on our side, and map out the CMTime based on UTC, etc.

If we have gaps is there a way with AVPlayer/AVPlayerItem/AVAsset/AVAssetTrack.... to map CMTime and program date in a way that we can seek? So if we wanted to seek to UTC time X, how do we map that to CMTime?

I should add, I know there is seekToDate, which I'm guessing is the answer. However, how do we scrub the iframe track with that given it doesn't accept before/after tolerances?

Thanks.

HLS AVPlayerItem producing unknown error, -15419
 
 
Q