Duration is occasionally showing as double when upgrading from 1.2.0 to 1.2.1

[byumark]

What version of Hls.js are you using?

1.2.1

What browser (including version) are you using?

Multiple

What OS (including version) are you using?

Multiple

Test stream

No response

Configuration

{ autoStartLoad: false }

Additional player setup steps

No response

Checklist

• The issue observed is not already reported by searching on Github under https://github.com/video-dev/hls.js/issues
• The issue occurs in the stable client (latest release) on https://hlsjs.video-dev.org/demo and not just on my page
• The issue occurs in the latest client (main branch) on https://hlsjs-dev.video-dev.org/demo and not just on my page
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream

Steps to reproduce

1. We have been unable to reproduce this issue on our end, but some of our users have experienced it
2. The user plays a video

Expected behaviour

The duration on the video player shows accurately and the video plays correctly

What actually happened?

The duration shows about double the actual duration and when the player gets to the end of the actual duration (middle of the doubled duration), then it just starts to buffer. This issue doesn't affect every video for this subset of users.

This does not seem to occur in hls.js v1.2.0 and appears to have regressed in v1.2.1. @robwalch has a hunch that it is related to #4849

Console output

Unable to reproduce

Chrome media internals output

No response

[robwalch]

@nklhtv have you ever encountered this issue?

I suspect this issue is related to media where duration is only available in segment index boxes (sidx and no trun or missing tfhd sample duration). The segment index boxes either have overlapping sub-segments (earliest presentation time + duration), or the HLS playlist segments reference those sub-segments by byte-range and accounting for all sub-segment durations exceeds the byte-range addressed duration.

[robwalch]

I don't plan to reverse @nklhtv's change, but may put some guard rails on the segment duration hls.js is willing to accept from fmp4 parsing when compared to the playlist time. Even if we address the missing earliestPresentationTime parsing and identify overlap, from what I can tell total sidx duration will be the duration of the mp4 file which is not necessarily the segments duration with byte-range addressed segemnts.

[byumark]

Hi @robwalch , we're looking into this issue on our end again. As you may recall, we thought that this might be related to sidx, but I recall that the fix you made didn't appear to help. Our content is HLS, so I'm not sure that it has sidx data. I was looking over the code changes from 1.2.0 to 1.2.1 and saw other changes that seemed like they could affect duration.

In the file src/demux/base-audio-demuxer.ts there are the following changes:

Original:

  resetTimeStamp() {}

  resetContiguity(): void {}

Modified:

  resetTimeStamp(deaultTimestamp) {
    this.initPTS = deaultTimestamp;
    this.resetContiguity();
  }

  resetContiguity(): void {
    this.basePTS = null;
    this.frameIndex = 0;
  }

Original:

export const initPTSFn = (
  timestamp: number | undefined,
  timeOffset: number
): number => {
  return Number.isFinite(timestamp as number)
    ? timestamp! * 90
    : timeOffset * 90000;
};

Modified:

export const initPTSFn = (
  timestamp: number | undefined,
  timeOffset: number,
  initPTS: number | null
): number => {
  if (Number.isFinite(timestamp as number)) {
    return timestamp! * 90;
  }
  return timeOffset * 90000 + (initPTS || 0);
};

There's also this change in src/loader/playlist-loader.ts, but it only seems to be related to files with sidx data:

Original:

      if (frag.initSegment) {
        frag.initSegment.setByteRange(String(sidxInfo.moovEndOffset) + '@0');
      }

Modified:

      if (frag.initSegment) {
        const moovBox = findBox(data, ['moov'])[0];
        const moovEndOffset = moovBox ? moovBox.length : null;
        frag.initSegment.setByteRange(String(moovEndOffset) + '@0');
      }

Could any of these changes, mixed with something weird going on with the browser, affect the video duration being displayed on the player? This is only affecting a small group of our users and they all seem to be Windows. We have not been able to reproduce the issue on our end.

[nklhtv]

@robwalch That is exactly the use-case i have, i have hls streams where duration is only available in segment index boxes (sidx and no trun or missing tfhd sample duration)
@byumark hls stream that uses mp4 segments could contain sidx atoms. Is it possible to give us an example m3u8 playlist that causes the issue?

[robwalch]

Please file a new issue with sample content that reproduces a bug. There are no known issues with fragment duration calculation. This issue is closed.

[nklhtv]

The segments used by @byumark are ts, which should mean that parsing sidx is not involved here.

[byumark]

@robwalch Unfortunately, we have never been able to reproduce it on our own. We have been able to see the double duration in Mux Data for users that claim to be seeing it. If we are able to have a user reproduce it for us, is there anything we can do on their computer to get valuable information that would help us understand it better or even help us reproduce it ourselves?

[robwalch]

On the latest release (v1.5.12), if you can reproduce the issue, examine the level details and fragment list HLS is currently using and compare it to both video.duration and the HLS Playlist content.

Do the EXTINF durations in the playlist add up to hls.levels[hls.currentLevel].details.totalduration?

How do they compare to the durations of parsed segments (hls.levels[hls.currentLevel].details.fragments)?

You might need to examine all loaded level details not just hls.currentLevel.

Does the issue happen only after a switch? Are the timestamps consistent between variants?

Enable debug logs to save the output and share it here. Init PTS is logged and there are warnings for a variety of media parsing issues.

[robwalch]

The segments used by @byumark are ts, which should mean that parsing sidx is not involved here.

There's nothing that I can identify in TS handling that would produce the issue described. The only logical and reproducible regression between 1.2.0 and 1.2.1 for such an outcome is what was found and fixed in #6192. That is not to say you aren't facing a real issue. It sounds like a browser or library issue or perhaps something odd about the media (although if it was the media we'd expect the problem to present on all platforms). Once you have something that I can reproduce, I can look into root cause and a fix.

[byumark]

We were able to get logs from one of the users experiencing this issue:

[log] > Debug logs enabled for "Hls instance" in hls.js version 1.5.12
[log] > stopLoad
[log] > loadSource:https://***/master.m3u8
[log] > [stream-controller]: Trigger BUFFER_RESET
[log] > attachMedia
[log] > [buffer-controller] created media source: MediaSource
[error] > Media element src was set while attaching MediaSource (blob:https://***/0b009bfe-4085-429b-ab56-ec9261215b9d > https://***/video/delivery/api/v1/storyboards/5e8f8fba-8bf2-4722-b07e-f04c6b2b3091/7c5960c1-4f22-4c81-b2a0-1b6da5ad98b6)
[log] > [buffer-controller] Media source opened
[log] > [level-controller]: manifest loaded, 7 level(s) found, first bitrate: 1331623
[log] > setting initial bwe to 1331623
[log] > [buffer-controller] 2 bufferCodec event(s) expected
[log] > startLoad(414.287246)
[log] > [abr] picked start tier {"codecSet":"avc1,mp4a","videoRanges":["SDR"],"preferHDR":false,"minFramerate":23.976,"minBitrate":392276}
[info] > [abr] switch candidate:4->4 adjustedbw(1331623)-bitrate=0 ttfb:0.1 avgDuration:0.0 maxFetchDuration:4.0 fetchDuration:0.1 firstSelection:true codecSet:avc1,mp4a videoRange:SDR hls.loadLevel:-1
[log] > [level-controller]: Switching to level 4 (540p SDR avc1,mp4a @1331623) from level -1
[log] > [audio-track-controller]: Updating audio tracks, 1 track(s) found in group(s): program_audio
[log] > [audio-track-controller]: Switching to audio-track 0 "Alternate Audio" lang:eng group:program_audio channels:undefined
[log] > [audio-stream-controller]: Reset loading state
[log] > [audio-stream-controller]: STOPPED->IDLE
[log] > [audio-stream-controller]: IDLE->WAITING_TRACK
[log] > [level-controller]: Loading level index 4 with https://***/hls_960x540.m3u8
[log] > [stream-controller]: STOPPED->IDLE
[log] > [audio-track-controller]: loading audio-track playlist 0 "Alternate Audio" lang:eng group:program_audio
[log] > [audio-stream-controller]: WAITING_TRACK->STOPPED
[log] > [audio-stream-controller]: STOPPED->WAITING_TRACK
[log] > [subtitle-stream-controller]: STOPPED->IDLE
[log] > [audio-track-controller]: Audio track 0 "Alternate Audio" lang:eng group:program_audio loaded [1-58]
[log] > [stream-controller]: Level 4 loaded [1,58][part-58--1], cc [0, 0] duration:287
[log] > [buffer-controller] Updating Media Source duration to 287.000
[log] > [stream-controller]: Loading fragment 58 cc: 0 of [1-58] level: 4, target: 414.287
[log] > [stream-controller]: IDLE->FRAG_LOADING
[log] > [audio-track-controller]: Audio track 0 "Alternate Audio" lang:eng group:program_audio loaded [1-58]
[log] > [audio-stream-controller]: Audio track 0 loaded [1,58][part-58--1],duration:287
[log] > [audio-stream-controller]: WAITING_TRACK->IDLE
[log] > [audio-stream-controller]: Loading fragment 58 cc: 0 of [1-58] track: 0, target: 414.287
[log] > [audio-stream-controller]: IDLE->FRAG_LOADING
[log] > [audio-stream-controller]: Unknown video PTS for cc 0, waiting for video PTS before demuxing audio frag 58 of [1 ,58],track 0
[log] > [audio-stream-controller]: FRAG_LOADING->WAITING_INIT_PTS
[log] > [audio-stream-controller]: Loaded fragment 58 of level 0
[log] > [transmuxer-interface, main]: Starting new transmux session for sn: 58 p: -1 level: 4 id: 1
[log] > [mp4-remuxer]: ISGenerated flag reset
[log] > [mp4-remuxer]: initPTS & initDTS reset
[log] > [mp4-remuxer]: reset next timestamp
[log] > 25998292/25994538:unknown NAL 11 
[log] > [stream-controller]: FRAG_LOADING->PARSING
[log] > [stream-controller]: Init video buffer, container:video/mp4, codecs[level/parsed]=[avc1.4d401f/avc1.4d401f]
[log] > [buffer-controller] 1 bufferCodec event(s) expected video
[log] > [audio-stream-controller]: InitPTS for cc: 0 found from main: -25466247
[log] > [audio-stream-controller]: WAITING_INIT_PTS->FRAG_LOADING
[log] > [transmuxer-interface, audio]: Starting new transmux session for sn: 58 p: -1 level: 0 id: 1
[log] > ADTS sync word found !
[log] > [mp4-remuxer]: ISGenerated flag reset
[log] > [mp4-remuxer]: initPTS & initDTS reset
[log] > [mp4-remuxer]: reset next timestamp
[log] > manifest codec:mp4a.40.2, ADTS type:2, samplingIndex:3
[log] > parsed codec:mp4a.40.5, rate:48000, channels:2
[log] > [audio-stream-controller]: FRAG_LOADING->PARSING
[log] > [audio-stream-controller]: Init audio buffer, container:audio/mp4, codecs[level/parsed]=[mp4a.40.2/mp4a.40.5]
[log] > [buffer-controller] 0 bufferCodec event(s) expected audio
[log] > [buffer-controller] creating sourceBuffer(video/mp4;codecs=avc1.4d401f)
[log] > [buffer-controller] creating sourceBuffer(audio/mp4;codecs=mp4a.40.2)
[log] > [stream-controller]: Alternate track found, use video.buffered to schedule main fragment loading
[log] > [transmuxer.ts]: Flushed fragment 58 of level 0
[log] > [audio-stream-controller]: PARSING->PARSED
[log] > [stream-controller]: Loaded fragment 58 of level 4
[log] > [transmuxer.ts]: Flushed fragment 58 of level 4
[log] > [stream-controller]: PARSING->PARSED
[log] > [stream-controller]: media seeking to 287.000, state: PARSED
[log] > [audio-stream-controller]: media seeking to 287.000, state: PARSED
[log] > [subtitle-stream-controller]: media seeking to 287.000, state: IDLE
[log] > [stream-controller]: media seeking to 287.783, state: PARSED
[log] > [audio-stream-controller]: media seeking to 287.783, state: PARSED
[log] > [subtitle-stream-controller]: media seeking to 287.783, state: IDLE
[log] > [stream-controller]: media seeking to 299.026, state: PARSED
[log] > [audio-stream-controller]: media seeking to 299.026, state: PARSED
[log] > [subtitle-stream-controller]: media seeking to 299.026, state: IDLE
[log] > [stream-controller]: media seeking to 310.269, state: PARSED
[log] > [audio-stream-controller]: media seeking to 310.269, state: PARSED
[log] > [subtitle-stream-controller]: media seeking to 310.269, state: IDLE
[log] > [stream-controller]: media seeking to 321.490, state: PARSED
[log] > [audio-stream-controller]: media seeking to 321.490, state: PARSED
[log] > [subtitle-stream-controller]: media seeking to 321.490, state: IDLE
[log] > [stream-controller]: media seeking to 332.711, state: PARSED
[log] > [audio-stream-controller]: media seeking to 332.711, state: PARSED
[log] > [subtitle-stream-controller]: media seeking to 332.711, state: IDLE

This is Windows 10, Google Chrome Version 126.0.6478.127.

[robwalch]

Hi @byumark,

Here's a breakdown of what we can see in these logs related to duration. I don't see anything pointing to an issue with hls.js. If anything the start position at the beginning and seeking at the end suggest that the application using hls.js expects the duration of the content to be longer than it actually is.

Loading begins with the intent to seek to 414s:

[log] > startLoad(414.287246)

The HLS media playlists (main and alt-audio) have segment durations that each add up to 287s:

[log] > [stream-controller]: Level 4 loaded [1,58][part-58--1], cc [0, 0] duration:287
[log] > [audio-stream-controller]: Audio track 0 loaded [1,58][part-58--1],duration:287

The MediaSource duration is set to 287 (there are no other logs of duration being set):

[log] > [buffer-controller] Updating Media Source duration to 287.000

The last segment of each playlist (no.58 of 1-58) is loaded (the closest to the unaccessible start position of 414):

[log] > [stream-controller]: Loading fragment 58 cc: 0 of [1-58] level: 4, target: 414.287
[log] > [audio-stream-controller]: Loading fragment 58 cc: 0 of [1-58] track: 0, target: 414.287

In the MPEGTS tranmsuxer an unknown NAL unit type is encountered (25994538/90000 = 288.82). NAL unit type 11 signals end of stream and is not expected/handled/needed by hls.js which relies on an EXT-X-ENDLIST tag in the Playlists to signal EOS:

[log] > 25998292/25994538:unknown NAL 11 

The last segment no.58 starts has a starting PTS of 25466247 (25466247/90000 = 282.95)

[log] > [audio-stream-controller]: InitPTS for cc: 0 found from main: -25466247

The remaining logs show attempts to seek (HTMLMediaElement "seeking" events) past the last stated duration of the media. These are not resolves and there is no other activity from hls.js. If these seeks were issued by hls.js there would be log messages explaining why. They were not.

[log] > [stream-controller]: media seeking to 287.000, state: PARSED
...
[log] > [stream-controller]: media seeking to 332.711, state: PARSED

So it seems you have an application using hls.js that expects the duration to be greater than what is available in the media and that attempts to seek past the end. Perhaps it is also responsible for displaying the incorrect duration (and not hls.js)?

[byumark]

@robwalch thanks for the thorough explanation. I think what's happening with the initial seek is that we store the playhead location in local storage so that users can pick up where they left off when they come back to the video. My hunch is that the user found a video with the double duration problem, manually seeked into the time of the video that doesn't really exist, and hit refresh on the page. That could explain why the logs show that the player is immediately seeking into a time on the video that doesn't really exist.

I'll try to see if the user can test the master manifest in the hls.js demo page and see if the results are any different.

[robwalch]

The logs are missing fragBufferedComplete logs. After media is parsed (PARSING->PARSED), it is expected to be appended if it indeed contained any audio and/or video. For a VOD stream, these would be followed by EOS handling and the stream controllers switching to the ENDED state.

"[stream-controller]:" – "Buffered main sn: 0 of level 3 (frag:[0.000-10.023] > buffer:[0.023-10.008])"

When I attempt to seek in Chrome by setting currentTime to a value greater than duration, the seeking and seeked events do not report a currentTime greater than that of the last sample time appended to the media. Is it possible that your last TS segments has some sample with rogue media timestamps following the one with the EOS NAL unit?

[robwalch]

We should add a log line in onFragParsed with the frag times matching the logs from fragBufferedComplete. This will help troubleshoot issues with parsed media timestamps that never make it thought the appending process.

@byumark if you could provide just those segments (last audio and video) it would help to isolate the issue.

[byumark]

@robwalch I can for sure provide those segments. Is there a good way to do that without sharing them publicly?

Also, we just got off of the phone with our user and the problem did occur on the hlsjs demo page. Here are the logs from it.

Using Hls.js config: Object
[log] > Debug logs enabled for "Hls instance" in hls.js version 1.5.13
[log] > stopLoad
[log] > loadSource:https://***/master.m3u8
[log] > [stream-controller]: Trigger BUFFER_RESET
[log] > attachMedia
[log] > [buffer-controller] created media source: MediaSource
[log] > [buffer-controller] Media source opened
[log] > [level-controller]: manifest loaded, 7 level(s) found, first bitrate: 1331623
[log] > setting initial bwe to 1331623
[log] > [buffer-controller] 2 bufferCodec event(s) expected
[log] > [abr] picked start tier {"codecSet":"avc1,mp4a","videoRanges":["SDR"],"preferHDR":false,"minFramerate":23.976,"minBitrate":392276}
[info] > [abr] switch candidate:4->4 adjustedbw(1331623)-bitrate=0 ttfb:0.1 avgDuration:0.0 maxFetchDuration:4.0 fetchDuration:0.1 firstSelection:true codecSet:avc1,mp4a videoRange:SDR hls.loadLevel:-1
[log] > startLoad(-1)
[log] > [level-controller]: Switching to level 4 (540p SDR avc1,mp4a @1331623) from level -1
[log] > [audio-track-controller]: Updating audio tracks, 1 track(s) found in group(s): program_audio
[log] > [audio-track-controller]: Switching to audio-track 0 "Alternate Audio" lang:eng group:program_audio channels:undefined
[log] > [audio-stream-controller]: Reset loading state
[log] > [audio-stream-controller]: STOPPED->IDLE
[log] > [audio-stream-controller]: IDLE->WAITING_TRACK
[log] > [level-controller]: Loading level index 4 with https://***/hls_960x540.m3u8
[log] > [stream-controller]: STOPPED->IDLE
[log] > [audio-track-controller]: loading audio-track playlist 0 "Alternate Audio" lang:eng group:program_audio
[log] > [audio-stream-controller]: WAITING_TRACK->STOPPED
[log] > [audio-stream-controller]: STOPPED->WAITING_TRACK
[log] > [subtitle-stream-controller]: STOPPED->IDLE
[log] > [stream-controller]: Level 4 loaded [1,58][part-58--1], cc [0, 0] duration:287
[log] > [buffer-controller] Updating Media Source duration to 287.000
[log] > [stream-controller]: Loading fragment 1 cc: 0 of [1-58] level: 4, target: 0
[log] > [stream-controller]: IDLE->FRAG_LOADING
[log] > [audio-track-controller]: Audio track 0 "Alternate Audio" lang:eng group:program_audio loaded [1-58]
[log] > [audio-stream-controller]: Audio track 0 loaded [1,58][part-58--1],duration:287
[log] > [audio-stream-controller]: WAITING_TRACK->IDLE
[log] > [audio-stream-controller]: Loading fragment 1 cc: 0 of [1-58] track: 0, target: 0
[log] > [audio-stream-controller]: IDLE->FRAG_LOADING
[log] > injecting Web Worker for "audio"
[log] > [audio-stream-controller]: Unknown video PTS for cc 0, waiting for video PTS before demuxing audio frag 1 of [1 ,58],track 0
[log] > [audio-stream-controller]: FRAG_LOADING->WAITING_INIT_PTS
[log] > [audio-stream-controller]: Loaded fragment 1 of level 0
[log] > Debug logs enabled for "audio" in hls.js version 1.5.13
[log] > injecting Web Worker for "main"
[log] > [transmuxer-interface, main]: Starting new transmux session for sn: 1 p: -1 level: 4 id: 1
        discontinuity: true
        trackSwitch: true
        contiguous: false
        accurateTimeOffset: true
        timeOffset: 0
        initSegmentChange: true
[log] > [stream-controller]: Loaded fragment 1 of level 4
[log] > Debug logs enabled for "main" in hls.js version 1.5.13
[log] > [mp4-remuxer]: ISGenerated flag reset
[log] > [mp4-remuxer]: initPTS & initDTS reset
[log] > [mp4-remuxer]: reset next timestamp
[log] > 25998292/25994538:unknown NAL 11 
[log] > [stream-controller]: FRAG_LOADING->PARSING
[log] > [stream-controller]: Init video buffer, container:video/mp4, codecs[level/parsed]=[avc1.4d401f/avc1.4d401f]
[log] > [buffer-controller] 1 bufferCodec event(s) expected video
[log] > [audio-stream-controller]: InitPTS for cc: 0 found from main: 183753
[log] > [audio-stream-controller]: WAITING_INIT_PTS->FRAG_LOADING
[log] > [transmuxer-interface, audio]: Starting new transmux session for sn: 1 p: -1 level: 0 id: 1
        discontinuity: true
        trackSwitch: true
        contiguous: false
        accurateTimeOffset: false
        timeOffset: 0
        initSegmentChange: true
[log] > [transmuxer.ts]: Flushed fragment 1 of level 4
[log] > [stream-controller]: PARSING->PARSED
[log] > ADTS sync word found !
[log] > [mp4-remuxer]: ISGenerated flag reset
[log] > [mp4-remuxer]: initPTS & initDTS reset
[log] > [mp4-remuxer]: reset next timestamp
[log] > manifest codec:mp4a.40.2, ADTS type:2, samplingIndex:3
[log] > parsed codec:mp4a.40.5, rate:48000, channels:2
[log] > [audio-stream-controller]: FRAG_LOADING->PARSING
[log] > [audio-stream-controller]: Init audio buffer, container:audio/mp4, codecs[level/parsed]=[mp4a.40.2/mp4a.40.5]
[log] > [buffer-controller] 0 bufferCodec event(s) expected audio
[log] > [buffer-controller] creating sourceBuffer(video/mp4;codecs=avc1.4d401f)
[log] > [buffer-controller] creating sourceBuffer(audio/mp4;codecs=mp4a.40.2)
[log] > [stream-controller]: Alternate track found, use video.buffered to schedule main fragment loading
[log] > [transmuxer.ts]: Flushed fragment 1 of level 0
[log] > [audio-stream-controller]: PARSING->PARSED
[log] > [audio-stream-controller]: Buffered audio sn: 1 of track 0 (frag:[0.000-286.848] > buffer:[0.000-286.848])
[log] > [audio-stream-controller]: PARSED->IDLE
[log] > [stream-controller]: Buffered main sn: 1 of level 4 (frag:[0.000-286.870] > buffer:[0.000-286.870])
[log] > [stream-controller]: PARSED->IDLE
[info] > [abr] switch candidate:4->6 adjustedbw(16200323)-bitrate=12628819 ttfb:0.6 avgDuration:286.9 maxFetchDuration:286.9 fetchDuration:64.1 firstSelection:false codecSet:avc1,mp4a videoRange:SDR hls.loadLevel:4
[log] > [stream-controller]: Adapting to level 6 from level 4
[log] > [level-controller]: Switching to level 6 (1080p SDR avc1,mp4a @3571504) from level 4
[log] > [level-controller]: Loading level index 6 with https://***/hls_1920x1080.m3u8
[log] > [stream-controller]: IDLE->WAITING_LEVEL
[log] > [audio-stream-controller]: Loading fragment 2 cc: 0 of [1-58] track: 0, target: 286.848
[log] > [audio-stream-controller]: IDLE->FRAG_LOADING
[log] > [stream-controller]: Level 6 loaded [1,58][part-58--1], cc [0, 0] duration:287
[log] > [stream-controller]: WAITING_LEVEL->IDLE
[log] > [audio-stream-controller]: Loaded fragment 2 of level 0
[log] > [audio-stream-controller]: FRAG_LOADING->PARSING
[log] > [transmuxer.ts]: Flushed fragment 2 of level 0
[log] > [audio-stream-controller]: PARSING->PARSED
[log] > [audio-stream-controller]: Buffered audio sn: 2 of track 0 (frag:[286.848-573.739] > buffer:[0.000-573.739])
[log] > [audio-stream-controller]: PARSED->IDLE

The video initially plays with the player showing 4:47 as the duration. At about the 2 second mark it updated to 9:33. Based on these new logs, maybe it is not be related to the last segment?

[robwalch]

Could there be an issue with the byte-ranges or byte-range responses on the audio? Each one appears to take up the entire duration of the media. This suggests that the client received all the audio data instead of the range pertaining to the segment requested:

[audio-stream-controller]: Buffered audio sn: 1 of track 0 (frag:[0.000-286.848] > buffer:[0.000-286.848])
[audio-stream-controller]: Buffered audio sn: 2 of track 0 (frag:[286.848-573.739] > buffer:[0.000-573.739])

[robwalch]

It looks like each audio segment request is coming back with a response containing the entire audio program. In v1.2 this might have just appended over itself. In v1.2.1 hls.js tries to make contiguous appends for what should be contiguous audio segments. That might be why this is seen as a regression, but it does not appear to be the fault of hls.js that the response does not contain the byte-range requested (based on offline examination of playlist and HAR files showing the byte-range requests are being made correctly).

I'll be adding some logs with #6549 to show parsed times before appending (that would have helped with logs in #6191 (comment)). I also made a branch with additional logging for byte-ranges and bytes loaded and warning when there is a discrepancy in c7e9875. I do not intend to merge or ship that as that information is available in the network tab and can be captured in HAR files. The timestamps we already have ([0.000-286.848] for a single segment) make it obvious enough that there is an issue with the media delivered.

[byumark]

We have concluded that this issue is not related to hls.js. When hls.js requests segments of media it uses a Range header to get the desired segments. The response should include a Content-Range header that has the same requested range. In the case of this issue, users have security software that seems to remove the Range header from audio requests.

The users seeing this double duration issue are requesting audio as expected with a Range header of a range of bytes. In their case, however, the Content-Range header on the response does not exist. The Content-Length header on the response has a value which equals the length of the entire audio file, rather than a chunk of it. HLS.js then makes that request for audio one more time and gets the same response, which causes the duration to think it is twice the duration because it is loading two full audio files.

When the security software is disabled, the issue goes away.