"Range"/"Partial Content" support for Chrome: Part 2
Closed this issue · 2 comments
Hi,
See the prehistory at #92.
Today I've tested the version 0.7.0_2.
Browser: Chromium (version 52.0.2743.116 Built on Ubuntu).
Update (2016 Oct 10):
-- The same results as described below are found for Chrome 53.0.2785.143 (64-bit)
-- But none of issues described below encounter on Firefox: on FF all files play and seek correctly.
Here are the results.
1️⃣ I can correctly seek audio files that are played with the help of the <audio ...> tag and with size at least not more than 3.1 MB.
🔴 But if I use <audio preload="auto" ...> I encounter cases when the file starts playing, then suddenly resets and restarts from the 32768-th byte. In such cases the browser request contains Range=32768-, and the server indicates in its response that it sends range from 32768 to the end of the file. But in fact the player plays the file from the start (from the 0-th byte), and then stops playing not exactly at the end of the audio file but at the end minus 32768 bytes, in other words, it cut the file.
2️⃣ There are problems with seeking if the file size is about 16MB. If I move the slider, the player always plays from the start of the file, not from the position indicated by the slider. Checking the console, I see that after every change of the slider position the browser sends a new request with Range=[NewPosition]- (e.g., Range=123547-). The server answers with headers that indicate that [NewPosition]-[EndOfFile] bytes are sent. But actually it looks like the player gets 0-[EndOfFile-NewPosition] bytes.
Moreover, the listing of such a file loading (size = 15,964,411 bytes, playing time = 33m : 11s, no seeking, no transformation of the initial file) looks like that:
- Initial request-response:
- First portion:
- Next portions:
- It fails with the error:
- After that the player doesn't stop playing, it sends a new request:
*... and new portions of bytes are (giving in sum the total file size):
- Then it reaches the end time (33:11) and stops.
Some thoughts
✅ Two ideas come to my mind after that testing.
- There could be something quite easy that leads to sending bytes from 0, not from a required position
- There could be some other reason for the fail
net::ERR_CONTENT_LENGTH_MISMATCH
If some other info could be useful and necessary, I'll be glad to provide it.