In the Editor, we make many (hundreds) of these calls and everything works as expected. However, when testing it in a WebGL build, typically in the 2nd session, the .Send() call simply stalls at certain assetbundles.
We noticed this previously when the call was made twice for the same assetbundle/url but there is no duplication in this case. I assume it is preparing to load from cache but it provides no error, no network request and the downloadProgress is always -1 which according to documentation means that .Send() isnt even called yet.
Has anyone experienced this or have an idea as to what might cause it?
I have a similar issue while trying to download too many asset bundles simultaneously (5 in our case), but that happens even in the editor (rare, but can happen). The UnityWebRequest basically never starts after calling send (progress never moves beyond 0). The request will either hang forever or eventually throw an error. I resolved it by adding my own timeout logic and if the progress is still 0 after the timeout I just abort and retry the request. It happens so rarely for us that this is an acceptable workaround.
I never have this problem if I download one asset bundle at a time so I think it’s something to do with loading many of them simultaneously. At any rate, it happens in the editor for me so I don’t think a webgl bug, but a UnityWebRequest bug.
I thought that might be the case so have actually throttled the requests but that didnt seem to change the outcome. I agree that it is probably a UWR bug but just rears its head for us consistently in WebGL - which is why I posted it here.
Well, so far no workaround has worked. We abort the UnityWebRequest if it times out and it still hangs (based on dox, .Abort() waits for .Send() to be called anyway). We also tried loading assetbundles one at a time and it still hangs on the .Send()…
You can’t yield on send to do the workaround, you need to constantly check the UnityWebRequest’s progress in a corountine or the update loop. Something like this:
while(urw is not done)
{
if (we timeout)
{
if (urw.downloadProgress == 0.0f)
{
urw.Abort();
yield return null;
yield return null;
yield return null;
urw.Dispose();
urw = null;
urw = UnityWebRequest.GetAssetBundle([web path], 0);
urw.Send();
[reset timeout window and keep waiting]
}
else
{
[throw real error]
}
}
else
{
yield return null;
}
}
That’s what we do in our test. We call a coroutine (passing in the UWR) which checks the progress every couple seconds. The problem is that the downloadProgress is always -1, meaning .Send() is actually never called on that UWR (according to docs):
Im beginning to think it is WebGL specific because it only seems to happen when assets are loaded from cache in the browser.
It looks like every UWR assetbundle request gets stuck on .Send() with a -1 downloadProgress value. The timeout retry does eventually seem to work but since it’s timing out on every single call, it doesn’t really help. Ill keep digging…
Well, I’ve wasted an entire day on troubleshooting this. Here’s my conclusion:
Making several (say 15) AssetBundle requests around the same time using UnityWebRequest w/request headers works fine the first time. Subsequent loads in WebGL of the same assetbundles seem to fail. I have to surmise that it is failing when loading the cached data from disk.
Replacing the exact same calls with the WWW API works as intended for all sessions in WebGL.
I vaguely remember you guys use the “better” asset bundle caching (CachedXMLHttpRequest), maybe you’re hitting a bug there? Does it still happen when you use just LoadFromCacheOrDownload?
Correct, but we have removed the CachedXMLHttpRequest plugin for the UWR tests, so it shouldnt be a factor. I don’t dare go back to LoadFromCacheOrDownload at this point.
WWW with the plugin is/was working fine, but I assume it will be deprecated at some point and wanted to upgrade everything to the newer API.
So just to be clear, any combination of UWR (not cached, “builtin unity caching”, CachedXMLHttpRequest caching) doesn’t work? And any combination of WWW (not cached, “builtin unity caching”, CachedXMLHttpRequest caching) works? I now wonder if we are in fact experiencing the same “general UWR bug” but in different ways.
I haven’t used WWW in a long time so I can’t be 100% sure my problem is a UWR only bug, but my “stall issue” happens even without caching so I guess I’m back to thinking my issue is different.
I’m having the exact problem but with my editor and some Android users report similar symptom too (not sure about the later part) so I’m switching back to WWW.LoadFromCacheOrDownload. My version is 5.5.4.
with exceptions from yours, my: don’t stall at all, but download has finished after additional time. May be it’s a bug in UnityWebRequest or a browser integration code
