I have a problem, like following scenario.
There is a static group contains asset_a and asset_b, and set bundle mode to pack together,build and load path is local, then build player content, there is a bundle named defaultlocalgroup_assets_all_111.bundle in the streaming assets folder. a catalog and a hash file in the remote location, release the binary.
Open the app, load asset_a and asset_b from defaultlocalgroup_assets_all_111.bundle as expected,everything is ok.
Next, i modified the asset_a,and prepare for content update,and build for content update,the catelog and hash file in the remote location has been updated, and contentupdate_assets_all_xxx.bundle generated in the remote location. and the meantime, asset bundles for staticcontent group is also built,and generate a new bundle named defaultlocalgroup_assets_all_222.bundle to the library\StreamingAssetsCopy folder.
So here comes the question, asset_b(unchanged) in the new catalog quote the new bundle(defaultlocalgroup_assets_all_222.bundle) ,but the app only has the original bundle named defaultlocalgroup_assets_all_111.bundle. and the remote location has only the contentupdate assets bundle,addresable system throw a exception when load asset_b, it can not find defaultlocalgroup_assets_all_222.bundle.
I feel different from what is said in the document.
"The build generates a content catalog, a hash file, and the asset bundles.
The generated content catalog has the same name as the catalog in the selected Player build and is overwritten as is the hash file. The hash file is loaded by the Player to determine if a new catalog is available. Assets that have not been modified are loaded from existing bundles that were shipped with the Player or already downloaded.
The Addressable Assets build system uses the content version string and location information from addressables_content_state.bin file to create the asset bundles. Asset bundles that do not contain updated content are written using the same file names as those in the build selected for the update. If an asset bundle contains updated content, a new asset bundle is generated that contains the updated content and is given a new file name so that it can coexist with the original. Only asset bundles with new file names must be copied to the location that hosts your content.
Asset bundles for StaticContent groups are also built, but they do not need to be uploaded to the content hosting location as they are not referenced by any Addressable asset entries."
We have a known bug surrounding updating a build with changes to static content. You start with
LocalBundle_123(contains x1,x2,x3)
then prepare/build for update and get
LocalBundle_456(contains x1,x2)
UpdateRemoteBundle_898(contains x3)
it should make a catalog that still has x1 & x2 point to the old LocalBundle_123, but it doesn’t. we’re working on it and should have that out in the next release.
2 weeks? I’m not exactly sure. I’d like to get a build out sooner, but the team is a bit light over the summer (lots of various vacations). And there’s a lot to fixing this the right way vs a quick hack.
If you need the quick hack to tide you over, you can stop appending the hash to all bundles. We append hash inside BuildScriptPackedMode in the method PostProcessBundles. Disable that, and the catalog will still be able to look at the old local bundle.
Heads up, this will be a two-stage fix. Coming out soon (hopefully this week) will be an option to choose per-group how the hash is included in the naming of bundles. If you choose “no hash” for all “static” bundles, then this bug won’t happen.
That’s just a workaround. We’ll have a real fix out some time later. Probably the following release. The reason it isn’t out this time is that it is much more involved and we want to make sure to test it thoroughly before releasing.
I guess I am encountering this problem in v1.5.0 with Unity 2019.2.0f1 as well, any updates on this problem is appreciated.
UPDATE: tried choosing no hash for all static bundles but since we have CRC enabled, the old static bundle is not loaded. Disabling CRC sounds like a shady hack for this problem, so I wish there are a better solution.
And to be honest this kinda breaks the most fundamental feature of the whole addressable system, I really hope the team can fix this asap
@ao_196419 The bug you raised has been closed fixed for Addressables 1.7.4 but i’m still seeing the same outcome in Addressable 1.8.4.
As mentioned disabling the crc check and setting the asset group bundle name to filename only does workaround this issue.
Did you ever manage to get static addressable group content-update to work without using this workaround?
This known bug was fixed a long time ago. So what you are seeing may be a new issue. Would it be possible to bug report this and show us what causes it?
It was a long time ago, but if I recall correct. The fix was to the content_state.bin file. So if you are attempting to update a release that was before the bug fix. You would still have the issue.
>“This bug is still on Addressables 1.14.2. Groups that are set to “Cannot Change Post Release”, shouldn’t be changed in any case, right?”
Content in the Groups can be changed, and those changes are detected in “Check for content update Restrictions” and required content can be moved to new remote Group. Now a bundle build occurs and the changed content (+anything that references it) are in new remote locations. The runtime can still use the old bundles with the unchanged content. So the Catalog is now expected to be changed point to the old content bundles for the unchanged content. It gets this information from the addressables_content_state.bin file. So if that is broken, or incorrect for the release. Then it will fail.
I previously switched to using the work around mentioned by unity_bill in this thread (setting “no hash” for all “static” bundles) and left that in place. Now we are looking to update from addressable version 1.16 to the 1.17.17, it seems that this work around no longer works.
I think it might have been due to this change
[1.17.0-preview] Fixed issue where Filename only bundle naming schemas were overwriting old bundles prematurely in content update.
So i’ve tried switching back to using the default addressables group config for our groups and i’m seeing the original issue reported in this thread reoccurring.
After our game client has downloaded a content update, the next attempt to load an asset in a static asset bundle generates this error…
Unable to open archive file: jar:file:///data/app/com.xxx.yyy.ml-5mnwbeEf7dtsxI0O7R3UeQ==/base.apk!/assets/aa/Android/default_assets_all_77dc2cd158884df8b1101803c129a11a.bundle
The content catalog has been updated, it is now trying to load from an asset bundle which doesn’t exist, the local bundle has a different guid value appended to it than the one which is trying to be loaded.
This is not as a result of the content_state.bin being generated from an older addressable version.
This sounds like a bug, either in the update/state file.
Unless you have tried to add anything to the local group. As that would then point to the new bundle in that build, rather than the existing bundle. As it doesn’t have that Asset there.
I would need to look at it locally to know for sure. Could you make a bug report demonstrating the problem?
Addressable 1.16.10
If the entry in group is a folder, the bug still exists.
In the function DetermineRequiredAssetEntryUpdates() in RevertUnchangedAssetsToPreviousAssetState class, folder entry’s guid can’t be found in contentUpdateContext.WriteData.AssetToFiles.
