Thanks for taking a look at this. Below is output of a simple stats script, fed a CDN log file. I have removed non-Roku agents; each section usually contains top 20 entries.
(Google Cloud Storage URLs because I can't attach stuff here. Shout and I'll make them more accessible if necessary)
Below it is a sample of all requests made by one IP address, showing the constant retries for a single segment
Raw request log for that same agent:
It occurred to me that the devices might be racing duplicate requests and cancelling the slowest, in order to e.g. cope with bad wifi. Unfortunately we (and most people) are billed by request at the application layer than actual transfers at the network layer.
I suspect each of these requests fetch a different range of the segment. The total amount of bytes downloaded should not be higher.
Does this CDN have issues with range requests? Is the bandwidth consumption for Roku devices higher, or is only the number of HTTP (partial) GET requests higher?
wmd1947 OP, did you ever figure this out? I'm seeing similar behavior during a particularly busy event and am looking for clues.
I verified the requests were indeed "partial content" responses, and the Roku boxes were passing a Range: header. I did not verify whether the sum of those partial responses is equivalent to a normal client, but according to our CDN reports, they most certainly are not.
This behaviour is unfortunately non-optional -- it's baked into the requirements spec for Roku-compatible HLS feeds.
We purchased a Roku device to test future configuration changes against, but I'm not hopeful of finding a solution.
If you are stuck dealing with per-request CDN pricing, consider moving to a CDN that does not feature such pricing. It's a lame solution. Thankfully Roku does not account for most of our traffic. If it did, probably we would consider more aggressive solutions, but for now the pain is manageable.
Really it would be so much better if the devices did not issue these requests by default. Other players (such as Video.js) only use partial content requests during seeking. It seems nonsensical to request partial content for an otherwise linear, live stream where the user will almost certainly consume a full MPEG chunk
Sorry I can't be of more assistance. If you find out anything please feel comment on the thread - would really love a solution to it.
Will do, and thanks so much for the quick response!
