We’re using Wowza 3.6.4.
We use a HLS VOD streaming application, streaming audio (m4a/mp3). We have a problem with timeouts occurring while accessing the chunks, which happens in this scenario:
The client (player) requests the m3u8 playlist, then the chunklist, then the AES key, and then starts sequentially requesting the audio chunks.
On the client we set it up to pre-buffer about 90 seconds ahead, so the client quickly requests about 9-10 chunks at the beginning of the stream (each chunk is 10 seconds long). Then the player may be playing for about 15-20 seconds before it requests a couple more chunks, etc.
Often, when the delay between chunk requests is bigger than 15 seconds, we see on the client side that the chunk request times out (timeout on the client side is set to 4 seconds), and the player retries the chunk request, and usually succeeds.
On the wowza server side, I always see the seek event logged in the access log in this scenario. The timestamp of the seek in wowza access log is the time when client retried the request (not of the original request which timed out). There are no stop and destroy events logged (I’ve changed newSessionTimeout from 8000 to 60000, and validSessionTimeout from 25000 to 1800000). I.e. in the access log, I see the play event, and then seek events occur when the client keeps a pause of 15-20 seconds between chunk requests.
- Is there a parameter which could be used to avoid timeouts when requesting chunks?
- Why/when does wowza treat a request to a chunk as a seek event?
(Note, as I’ve mentioned above, that the player makes sequential requests to the chunks, there is no real seeking occurring in the player).