It seems Viblast.js is not properly handling HTTP 410 responses on DASH segments.
We have a server with live content, that sends 410 instead of 404 to signal the players that a segment is definitely gone (eg. too far in the past), and prevent them to retry later.
Viblast tends to start one or two segment too late (which I saw in another port will be fixed later), as a result it tends to request segments that are no longer available.
In that case, the player receives an HTTP 410 but takes arround 10s to close the HTTP connection, before trying the next segment with 10s additional delay, wich increases the problem.
Some other js player don't have this issue and immediately move to the next segment when receiving the HTTP 410.
Attached: pcap for 1 segment
Thank you for the report.
Can you share a screen shot of the "Timings" tab?
It would be great if you can share a test stream or at least the manifest mpd (Arte.mpd) content.
Thank you for sharing the resources.
Can you share the content of the "Timings" tab?
In the network tab if you click on the request with 410 response code , you can see its details separated in different tabs.
What we need is a snapshot of the "Timings" tab, which is the last one. By default the dev tool opens the "Headers" tab, which is the first one.
Thank you again for the additional information.
As we do not have access to your streaming server, can you share the response headers for the request with 410 response code?
We tried to extract some values from the attached pcap, but we have to know the exact values for the headers, especially the "Content-length" one.
What we see as a particular response is:
HTTP/1.1 410 Lost File
without a body. Thus, the player waits until the entire content is received. The body is not sent and that is the reason why the timeout is triggered after 10 seconds.
Can you confirm if this is the case?
If yes, you have to fix the server response.