Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

static group bundle name has changed in catalog when build for content update

Discussion in 'Addressables' started by Marks001, Jul 1, 2019.

  1. Marks001

    Marks001

    Joined:
    Dec 11, 2014
    Posts:
    27
    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.

    Sorry for my poor english,thanks.
     
    Last edited: Jul 4, 2019
  2. Marks001

    Marks001

    Joined:
    Dec 11, 2014
    Posts:
    27
    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."
     
  3. unity_bill

    unity_bill

    Joined:
    Apr 11, 2017
    Posts:
    1,053
    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.
     
  4. Marks001

    Marks001

    Joined:
    Dec 11, 2014
    Posts:
    27
    Thank you for your reply, when will the next release be released? If it takes a long time,i will try to solve this bug temporarily.
     
  5. unity_bill

    unity_bill

    Joined:
    Apr 11, 2017
    Posts:
    1,053
    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.
     
  6. Marks001

    Marks001

    Joined:
    Dec 11, 2014
    Posts:
    27
    Thanks!
     
  7. unity_bill

    unity_bill

    Joined:
    Apr 11, 2017
    Posts:
    1,053
    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.
     
    danilonishimura likes this.
  8. dirty-rectangle

    dirty-rectangle

    Joined:
    Apr 23, 2015
    Posts:
    78
    Is there any update on this? I'm still seeing this occur with v1.4.0
     
  9. ao_196419

    ao_196419

    Joined:
    Jul 6, 2018
    Posts:
    17
    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 :(
     
    Last edited: Jan 12, 2020
  10. ao_196419

    ao_196419

    Joined:
    Jul 6, 2018
    Posts:
    17
  11. dirty-rectangle

    dirty-rectangle

    Joined:
    Apr 23, 2015
    Posts:
    78
  12. dirty-rectangle

    dirty-rectangle

    Joined:
    Apr 23, 2015
    Posts:
    78
    @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?
     
  13. NickZhao

    NickZhao

    Joined:
    Jun 22, 2018
    Posts:
    5
    @unity_bill The bug is still there on version 1.10.0
     
  14. better_walk_away

    better_walk_away

    Joined:
    Jul 12, 2016
    Posts:
    291
    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?
     
  15. errormee

    errormee

    Joined:
    Dec 26, 2014
    Posts:
    4
    This bug is still on Addressables 1.16.16
     
  16. andymilsom

    andymilsom

    Unity Technologies

    Joined:
    Mar 2, 2016
    Posts:
    294
    >"This bug is still on Addressables 1.16.16"

    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.
     
  17. dirty-rectangle

    dirty-rectangle

    Joined:
    Apr 23, 2015
    Posts:
    78
    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.
     
  18. andymilsom

    andymilsom

    Unity Technologies

    Joined:
    Mar 2, 2016
    Posts:
    294
    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?
     
  19. rookiemike

    rookiemike

    Joined:
    Jul 10, 2017
    Posts:
    4
    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.

    upload_2021-6-17_17-46-51.png