Fetching wrong byte range for HLS with fMP4 using BYTERANGE

[rkuroiwa]

Have you read the FAQ and checked for duplicate issues:
yes. I don't see a duplicate.

What version of Shaka Player are you using:
Shaka Player v2.1.0-117-gaf252c9-debug
at https://nightly-dot-shaka-player-demo.appspot.com/demo

Can you reproduce the issue with our latest release version:
N/A

Can you reproduce the issue with the latest code from master:
N/A

Are you using the demo app or your own custom app:
Demo app.

If custom app, can you reproduce the issue using our demo app:
N/A

What browser and OS are you using:
Linux with Chrome
Version 59.0.3071.115 (Official Build) (64-bit)

What are the manifest and license server URIs:
(you can send the URIs to [email protected] instead, but please use GitHub and the template for the rest)
HLS manifest at: https://storage.googleapis.com/wvtemp/rkuroiwa/hls_single_segment/single_segment.m3u8

(Just for comparison and repro) MPD manifest at: https://storage.googleapis.com/wvtemp/rkuroiwa/hls_single_segment/sintel_mpd_hls_compare.mpd

What did you do?
Used the HLS manifest and watched the network dev console.

What did you expect to happen?
For the second segment, the player fetched this (copy pasting HTTP request headers)
range:bytes=11316324-14165510

Where as it should be:
range:bytes=11316325-14165511

Looks like there is off by 1 error.
If you use the MPD manifest you get the second HTTP headers.

Although I see 3016 error, the MPD and the HLS playlist point to the same media file, so it looks like shaka-player is not appending the right buffer.

What actually happened?
Fetch range is "range:bytes=11316324-14165510"

Also the playback stops with an error after playing for 2 seconds.
It seems like after the first 2 seconds, the player tries to append the second subsegment to MSE.
The message in the console looks like this
"Shaka Error MEDIA.VIDEO_ERROR (3,,CHUNK_DEMUXER_ERROR_APPEND_FAILED: Append: stream parsing failed. Data size=131072 append_window_start=0 append_window_end=888.04)"

[ismena]

@rkuroiwa Thanks a lot for such a detailed repro that potentially saved me hours of debugging!
I think it is indeed an off by 1 error and will start working on the fix right away.

[joeyparrish]

The fix has been cherry-picked for v2.1.6.