Occasional Issue with releasing asset.

Some time when we call Release on a particular asset loaded by addressable
I get the following error

"Addressables.Release was called on an object that Addressables was not previously aware of. Thus nothing is being released"

This means that in AddressableImpl.cs, the member m_resultToHandle dictionary does not have the key containing the asset I'm trying to release. But my logs made sure the assets are loaded by addressable loadAsset call before trying to call release on this particular asset.

For Example:
1: Load audio clip asset called.
var bellClip=await Addressable.LoadAssetAsync<AudioClip>("Bell").Task;
2: Release the clip via Addressables.Release(bellClip);
3: Notice occassionally / in some scenario above error gets thrown.

 

Hey, TreyK-47 thanks for the response.
We are currently using Addressable Version 1.18.15 - August 03, 2021.

 

Hey @TreyK-47 any update on this?

 

Addressables.Release

expects either the loaded

AudioClip

(bellClip.Result) or its

AsyncOperationHandle

as far as I know, but it looks like you pass the

Task

instead.

 

Hey Andy (@andymilsom),

Thank you for addressing the issue.

In our actual implementation, we preload a bunch of assets (AudioClip in this scenario) using Addressables.LoadAssetsAsync with the label as a parameter. This happens before any asset with that lable is used. Once loading is done via the above call. This will generate one handle for the group of assets that areloaded which we will use to unload the assets at once when they are no longer needed.

We use Addressables.LoadAssetAsync<AudioClip>("AddressableName") whenever we require any Audioclip loaded in the above step, we synchronously acquire the clip as we already loaded the clip in the above step. Once the clip is played we release each clip individually. Each time we are calling Addressables.LoadAssetAsync we expect individual handle to be created in AddressableImpl.cs in m_resultToHandle dictionary (which it creates most of the time)
And we call release mirroring every load call once individual instances acquired are used up.

We are assuming the Above steps can be done rapidly as we are just incrementing and decrementing the internal reference count.

In one scenario we are synchronously loading a single clip 10 times over 5 seconds and unloading the same clip as each instance finish playing. (Just FYI)

We are refraining from using OperationHandles because we want our audio playing modules not to be aware of Addressable implementation, hence they only acquire AudioClips and Call Release On AudioClips.

Hope to hear from you guys soon. I am currently working on a reproduction sample project since this is happening randomly it might take a bit longer.

 

Hey @andymilsom
If the addressables implementation performs a lookup for handle when we pass the result, what happens in the scenario when the same asset(AudioClip in this scenario) is loaded more than once, and we pass the asset back to the release call?
Does the addressables implementation maintain a list of handles for an asset, or is it a 1-1 mapping? I ask this because a 1-1 mapping might cause this issue, and only the first release call might be able to release the asset, and other calls won't be able to release the asset, and throw errors where it won't be able to find the handle.

 

Guys,
We found the issue was with our code, we found out that we were trying to release the loaded audio clip immediately after loading it (Without waiting for a single frame), there is something with addressable where the loaded asset is not immediately registered as loaded in the above-mentioned dictionary it would take at least 1 frame I'm hoping.

This fault was happening because our module which was supposed to identify the end of the audio clip was miss-firing event at beginning of playing the audio clip. We had to write our own module for this because unity currently does not provide a way to know the end of audio clip playing because of complications with Audio effects involved.

If anyone finds this thread because of a similar issue, make sure to wait for at least one frame before trying to release a loaded asset, even if it is already in the memory. Even though unity provides you with the asset synchronously the addressable is asynchronous when registering the asset load request in its reference count dictionary.

This thread can be closed.
Thanks for the support and time.