My Addressables bug-reports and questions collection

[Peter77]

Hi David,

thank you for the reply, much appreciated and helpful. I have a few follow up questions. I hope it won’t take several weeks to reply, @TreyK-47 can you please ask David to take a look? Thank you.

@davidla_unity

in regards to Case 1344710 (…) Need to disable the Windows Defender Firewall to allow connections from Android devices.

I don’t know if that’s the issue. The problem is not that I can’t connect, the problem is that Addressables is stuck if the remote location can’t be reached. It does work when the remote location is reachable. However, perhaps it’s solved/workaround using the suggested “Request Timeout” too.

@davidla_unity

For both 1346825 and 1344710:
We have recently added some workarounds that better handle timeouts and error handling for the UnityWebRequests that those APIs use.

In what Addressables / Unity versions are these fixes available? We’re using 2019 LTS.

@davidla_unity

By default the timeout is 0, which UWR interprets as “infinite”. On the Content Packing & Loading schema on the groups you can change the Request Timeout under Advanced Options. Double check that that is some number above 0.

That’s excellent information. Until just now I assumed the timeout is not limited to “seconds while receiving no data”, but time-outs also when a download takes longer than the specified timeout (e.g. slow internet connection), which is the reason why I didn’t use a timeout so far.

Is this true for the catalog check/download as well? Because the tooltip for the “Catalog Download Timeout” does not specify “seconds while receiving no data”.

@davidla_unity

For 1355053, what I think we’re recommending for now is that you do something like:

var downloadSize = Addressables.GetDownloadSizeAsync(key);
yield return downloadSize;
if(downloadSize.Result < DriveInfo.AvailableFreeSpace)
    Addressables.DownloadDependenciesAsync(key);
else
   Do something else

This doesn’t take into account the uncompressed size, does it? The download size reported by GetDownloadSizeAsync and the size that’s required on the storage device to store/cache the uncompressed bundles is quite different according to my tests.

This code also doesn’t take into account the “Cache Clear Behaviour” setting. I don’t think it’s that simple to only check if enough space for GetDownloadSizeAsync is available on the storage device.

@davidla_unity

our solution is that when we detect an error when loading a cached file, we delete it from the cache and re-download it. You’re saying that this re-download is getting flagged as unacceptable by Apple standards?

That’s correct, the exact wording from Apple why the submission failed was:

@""

Guideline 4.2.3 - Design - Minimum Functionality
We were required to download or unpack additional resources to continue using your app; however, the size of the download was not disclosed, and we were not prompted to choose to download additional resources. If your app requires additional resources, you must disclose the size of the download and prompt users before doing so.

I guess it’s like that: If they find the issue during review you fail. If they don’t find it, you’re lucky.

Thanks again for the reply.