Yikes. I had completely forgotten about that AES-128 key read. The M3U8 classes are all synchronous, so I jammed the read in there with a bit of a hack to let it run async, and promptly forgot about it.
VLC does retries for the key as well, but it only reads the key when it starts reading the stream.
When looking at your stream, I saw a few things::
--- SM.Media.Web.HttpConnectionWebReader's GetByteArrayAsync() ignores the status code. This would not matter unless one changes the default reader. (I happened to be testing with it since I can easily hard-code a proxy that forces all the traffic through
--- The key is not cached the way that it should be. phonesm tried to cache the 16-bytes worth of key data in a Dictionary<> that was (unfortunately) recreated every time the playlist was refreshed. This bug was hidden by the Silverlight HttpClient's
cache; the WinRT HttpClient actually has a way of turning off the cache.
--- Nested retry handlers will do bad things (i.e., 3 retries of 3 retries is 9). There is now a pending change to the retry code to fix this by throwing a different exception when the retry count runs out. That way, the outer retry handler can know it came
from another retry handler.
-- The retry policy code needs some though. Part of the problem is that it predates the change to an IoC container; part is that it currently retries gateway timeout (504), request timeout (408), and internal server error (500). It's simple enough to change
the table in
--either at compile time or at runtime, but it needs some thought to avoid causing trouble (it's easy enough for a given stream, but there are some weird web servers out there).
-- Last, but not least, the AES-128 key reader did not do any retries at all. It may also have left unobserved Task exceptions floating around when there was a failure (which is bad).
--- Since no cancellation token was available where the key read happened, things can get stuck for as long as the HTTP stack feels like keeping it that way. No amount of mashing the stop button will speed things up.
As a minor nit, the server claims the key is UTF-8 encoded text; "application/octet-stream" would probably be better. (This did not cause any trouble with phonesm.)
Look for some changes in the next day or so. I was about to do some testing so I could push what I already had when I saw your last post an though I'd, "just take a quick look" (file that under, "famous last words").