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(“Bell”).Task;
2: Release the clip via Addressables.Release(bellClip);
3: Notice occassionally / in some scenario above error gets thrown.
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.
Thank you @Peter77
Thats correct. We recommend that you use the handle instead of the result where possible. This is because when you pass the result, then we will do a lookup for the handle. So using the handle directly resolves this.
As that would result in the error message 100% of the time, and you said that it only happens sometimes. I will work on the assumption that is a pseudo-code error and you are using a valid parameter.
awaiting a task immediately continues execution (from the internals of Addressables) to your code, so has the potential of causing unexpected behaviour. I checked on this and we make sure to track the handle before the task completes.
Although releasing an Asset essentially during the execution of loading the Asset (performing release directly after await handle.task) feels very bad. I cannot see anything that would mean that this should not work.
Would you be able to create a reproduction and submit a bug report that we can debug and find the cause locally?
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(“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.
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?
Unless there are regressions this should be handled. If you find its not then please let me know.
That being said, you should not release using Assets sometimes and Handles other times. This is likely to cause a problem with what was released.
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.