Issue with PlayAssetDelivery.RetrieveAssetBundleAsync() about play-unity-plugins

[jamcohen]

Thanks for bringing this to our attention.
What version of the plugin are you using?

That exception should only be thrown after PlayAssetDelivery.RetrieveAssetBundleAsync() is called multiple times with the same asset pack name. To prevent it, you'll need to keep track of the request object returned from that method and make sure that the request's IsDone property is true before calling RetrieveAssetBundleAsync() again.

Is it possible that you're losing the reference to the returned request object and calling RetrieveAssetBundleAsync() a second time for that asset pack?

It's very strange that you're seeing it persist after restarting the game, since the dictionary that we use to keep track of active requests is only in memory, which would get cleared.

That said, I'm looking into having those methods return the current active request instead of throwing an exception.

In the meantime could you maintain a dictionary of requests keyed by asset pack names? Then, in the catch block for that exception you could reference the last active request stored in the dictionary. Would that work for you?

[JEOptimal]

Thanks for getting back to me so fast!

I went through the logs and saw that the first request indeed is returned correctly, so no issue there!
So I'm doing as you suggest by keeping the request saved in my datastructure that relates to the assetpacks.

It's sounds great to have it always return the active request. I'm also wrapping the functions so I can simulate the downloads directly in editor, so right now I'll modify my own editor testing behavior to match this.

The real issue is still how to handle a request that goes into a strange pending state. Because if a new request was created each time the game was restarted that PlayAssetBundleRequest still went into the same pending state, and staying that way.

So what is the correct way of handling an PlayAssetBundleRequest that goes into pending state?

The reason I saw the problem with calling the RetrieveAssetBundleAsync() a second time is that I have an internal timer detecting if the download goes stale, that is pending without any other indication of what's going on. With the new code I will try to call

PlayAssetBundleRequest.AttemptCancel()
and then doing a new
RetrieveAssetBundleAsync()

Is this the correct way to retry an PlayAssetBundleRequest? Or how do I handle this? We've tried waiting for it to resume for 10min+, prior to adding the timeout. I also check for no internet connection so the timer doesn't count down in that case.

And we do usually download 5-6 other packs without any issues at all, prior to getting stuck. Our testing scenario for this is clearing app data / reinstalling the game and then doing a cloud load, that informs the game to download all the assetpacks required for the player to progress from the current save.

------ Update ------

After running with the modified code it seems to get stuck in the state AssetDeliveryStatus.Retrieving(After around 15 tries with 12 different packs each time). It enters this state even if the game is force closed and restarted on the device. But a full restart of the device resolves the issue.

So I'm wondering if the correct way is to add a timeout for all states, and have the timeout check against if any progress is made? Or if there just is no way for us to solve this issue from inside our game?

[jamcohen]

The best way to retry a PlayAssetBundleRequest is:

PlayAssetBundleRequest.AttemptCancel()
// Wait in a coroutine for PlayAssetBundleRequest.Error == AssetDeliveryErrorCode.Canceled
RetrieveAssetBundleAsync()

That said, you shouldn't need to retry requests unless the request fails with an error. The fact that the status is getting stuck on retrieving could be a bug on our end. If you drag open the notifications drawer on your device do you see a progress bar for that asset pack?
If you background the app and open it up again, does the download resume?

Play Asset Delivery talks to the Play Store app to handle the download. That's why you're seeing some download states persisting even when you close and open the app. If a download is stuck in Pending or Retrieving, it might mean the the Play Store is busy downloading something else. The notification drawer should show another download if that's the case.

If there is a legitimate timeout, for example the app loses network connection for some amount of time, your request should fail with an error: AssetDeliveryErrorCode.NetworkError.

You could try clearing the Play Store app data in between tests and seeing if that resolves the issue.

[jamcohen]

Also, could you provide a bugreport after reproducing the issue? That would help us debug why requests are getting stuck in the RETRIEVING state. You can post the bugreport here or email me directly at [email protected]. Whatever you prefer.

[JEOptimal]

The issue is really difficult to reproduce. So I might not be able to get you a bug report, especially now since it can automatically resolve the issue by calling AttemptCancel() and once again calling RetrieveAssetBundleAsync().

What also adds to the tedious task of testing this is that a new patch takes more than a day before it becomes available on beta testing. I'm not sure if this is because of using the playassetdelivery, but it used to take around 15 mins.

I'll send you a report if I'm able to catch one and a huge thanks for all your help!