When I test on that link :
http://demo1.devosvideo.com/autohls/wvit/wvit.m3u8
on demo page,
http://video-dev.github.io/hls.js/demo/?src=http%3A%2F%2Fdemo1.devosvideo.com%2Fautohls%2Fwvit%2Fwvit.m3u8&enableStreaming=true&autoRecoverError=true&enableWorker=true&dumpfMP4=false&levelCapping=-1&defaultAudioCodec=undefined
It works Well in IE Edge only, and Just load the first 1:40 minutes in all other browsers and stops loading any other data .
Thanks for Help .. :)
The server providing the m3u8 manifest is sending Cache-Control:public,max-age=86400 header, which is telling the browser that it should cache the manifest for 86400 seconds.
When the player requests any subsequent manifest update, it comes from the local browser cache instead of the server, hence the playback is stuck with whatever was in the m3u8 manifest at the time of the first request.
Since this is a live stream where a player will read each TS chunk only once and m3u8 manifest should be periodically refreshed, it might be feasible to disable client caching on the IIS server for your live stream completely.
https://www.iis.net/configreference/system.webserver/staticcontent/clientcache
Should you start using some caching proxy or CDN between a client and the server, only then it would make sense to set the TS chunks as cacheable for a couple of minutes and the m3u8 manifest for a couple of seconds.
@BucherTomas
I've understood your solution ..
But the thing that confuse me, Why it works well in IE Edge Only !!
If this problem is in the server providing the m3u8 manifest, why this problem doesn't generally happen with all browsers !!
Thanks a lot for your help .. :)
Edge has a different approach. Check the network tab in its developer console. It downloads the m3u8 manifest and caches it, then a couple of times afterwards it is getting it from the cache while honoring the Cache-Control header and likely only when it realizes that the buffer is running out, it begins to ignore the Cache-Control header for the following requests and starts asking your server again.
The Cache-Control header states max-age=86400 after all and since only upper limit is specified, it is up to the browser for how many seconds from the usable period it is going to use the file from the browser cache.
Most helpful comment
The server providing the m3u8 manifest is sending Cache-Control:public,max-age=86400 header, which is telling the browser that it should cache the manifest for 86400 seconds.
When the player requests any subsequent manifest update, it comes from the local browser cache instead of the server, hence the playback is stuck with whatever was in the m3u8 manifest at the time of the first request.
Since this is a live stream where a player will read each TS chunk only once and m3u8 manifest should be periodically refreshed, it might be feasible to disable client caching on the IIS server for your live stream completely.
https://www.iis.net/configreference/system.webserver/staticcontent/clientcache
Should you start using some caching proxy or CDN between a client and the server, only then it would make sense to set the TS chunks as cacheable for a couple of minutes and the m3u8 manifest for a couple of seconds.