Search Unity

Previous build not updating addressable changes

Discussion in 'Addressables' started by Mitjans_AmuseNetwork, Jan 11, 2019.

  1. Mitjans_AmuseNetwork

    Mitjans_AmuseNetwork

    Joined:
    Aug 3, 2017
    Posts:
    1
    I have observed that when I make some changes in my remote bundles and upload them to the server, my previous builds do not update their content. To try to isolate the problem I have create a new project where I instantiate prefabs with a certain label, and I still get the same issue:


    I have created a remote group that contains textures and prefabs and I have added a label to my prefabs. I then instantiate all the prefabs from my server (it all works fine). When I change the label and I rebuild/update my bundles, Unity creates a new ‘catalog_***.json’ and ‘**.hash’ files, which I upload with everything else to the server. If I then try to Instantiate again from a build already created, it still instantiates the old labeled prefabs, not the new ones. If I create a new build, it gets the proper labelled prefabs as it should. Here is the code:


    public AssetLabelReference labelRef;

    private void InstantiateAddressablesWithTag()
    {
    Addressables.LoadAssets<GameObject>(labelRef.labelString, null).Completed += OnAllLoaded;
    }

    private void OnAllLoaded(IAsyncOperation<IList<GameObject>> operation)
    {
    if (operation.Status == AsyncOperationStatus.Succeeded)
    {
    var result = operation.Result;
    int count = result.Count;
    for (int i = 0; i < count; i++)
    {
    GameObject go = Instantiate(result[i]);
    go.transform.position = UnityEngine.Random.insideUnitCircle * 10f;
    }
    }
    else
    {
    Debug.LogError("could not load objects with label: " + labelRef.labelString);
    }
    }


    I made sure that my bundles are marked as non ‘Static Content’, but it seems like the previous remote catalog (from previous version) still contains the old labels. I don’t understand what is happening as in my isolated project everything seems to work fine and there is nothing else in the code. I thought the already builded players should update their content from remote if any changes were found. I have also tried to clean the cache to force re-downloading the bundles.

    I have also done the ‘Build for Play Content’ procedure even though my addressables are dynamic and I thought this step wasn’t necessary and the issue was not solved.

    Also, the first time I launched play packed mode I got this exception, though I am not sure it is related (check attached image).

    What am I missing?


    For extra info: my unity version is 2018.3.1 and I am using Addressables System version 0.5.3.



    Thank you for your help!
     

    Attached Files:

    Muramasa666 and MNNoxMortem like this.
  2. MNNoxMortem

    MNNoxMortem

    Joined:
    Sep 11, 2016
    Posts:
    356
  3. rootor

    rootor

    Joined:
    Apr 7, 2013
    Posts:
    2
    If you are using 0.5.3 I think I know what the issue is. Each time you build the bundles the catalog file gets named by the current timestamp, e.g. catalog_xyz.* where 'xyz' is the time it was built. A client built with a certain catalog file will always download the same file with the timestamp it was built with. This means that even if you build new bundles and upload to the server the old client won't know about the new catalog file.

    I have solved it for now by building bundles with a hardcoded playerVersion (Basically cloning what is in
    AddressableAssetSettings.BuildPlayerContent() but passing "1" as playerVersion):

    Code (CSharp):
    1. public class BuildAddressables
    2. {
    3.     [MenuItem("Assets/Build Addressables")]
    4.     public static void Build()
    5.     {
    6.         Debug.Log(
    7.             $"Building Addressables Player Content to {Addressables.BuildPath}/{EditorUserBuildSettings.activeBuildTarget}");
    8.  
    9.         var settings = AddressableAssetSettingsDefaultObject.Settings;
    10.         if (settings == null)
    11.         {
    12.             Debug.LogError("Addressable Asset Settings does not exist.");
    13.             return;
    14.         }
    15.         if (Directory.Exists(Addressables.BuildPath))
    16.         {
    17.             try
    18.             {
    19.                 Directory.Delete(Addressables.BuildPath, true);
    20.             }
    21.             catch (Exception e)
    22.             {
    23.                 Debug.LogException(e);
    24.             }
    25.         }
    26.  
    27.         var buildContext = new AddressablesBuildDataBuilderContext(settings,
    28.             BuildPipeline.GetBuildTargetGroup(EditorUserBuildSettings.activeBuildTarget),
    29.             EditorUserBuildSettings.activeBuildTarget, EditorUserBuildSettings.development,
    30.             false, "1");
    31.         settings.ActivePlayerDataBuilder.BuildData<AddressablesPlayerBuildResult>(buildContext);
    32.     }
    33. }
    This way all clients, no matter when they were built, will always look at catalog_1.* and properly update content if hashes have changed.

    It can also be useful to set the 'ADDRESSABLES_LOG_ALL' preprocessor symbol in your project settings. It will print which catalog files are downloaded etc.
     
    MNNoxMortem likes this.
  4. MNNoxMortem

    MNNoxMortem

    Joined:
    Sep 11, 2016
    Posts:
    356
    @rootor wow. I will have to try that, that sounds incredibly useful for us. Thanks!
     
  5. MomochaZ

    MomochaZ

    Joined:
    Jun 20, 2013
    Posts:
    28
    Hello

    I have tried this method but the assets still doesn't update.
    The addressable log shows that it use the cache catalog_1 and doesn't update from remote.

    Does @MNNoxMortem update successfully?

    Thanks.
     
  6. MNNoxMortem

    MNNoxMortem

    Joined:
    Sep 11, 2016
    Posts:
    356
    @MomochaZ no because most changes we do are not detected by the the Prepare for Content Update. Some changes definetly do, but others don't and therefore we stopped even trying until the next release.
     
  7. MomochaZ

    MomochaZ

    Joined:
    Jun 20, 2013
    Posts:
    28
    Got it!

    Thanks for replying.
     
  8. dbarile

    dbarile

    Joined:
    Apr 14, 2015
    Posts:
    11
    @unity_bill

    I've been having the same issue, and found a lot of "we'll look into it" from you and other Unity team members on some older threads. Any new information or fixes on this matter?

    We have been uploading files to to a remote server, and when we Prepare then Build for content update, the old Addressable asset is still loading. Tried lots of variations of Static/Non-Static and also Cache/Do Not Cache in the Schemas. No success yet.

    Thanks for your help!
     
  9. whowh

    whowh

    Joined:
    Mar 7, 2019
    Posts:
    23
    Hi

    What is your addressable package version?
    The update from remote bundle works fine in version 0.6.7-preview for me.
     
  10. unity_bill

    unity_bill

    Unity Technologies

    Joined:
    Apr 11, 2017
    Posts:
    581
    Ok, a lot going on in this thread. I'll try to make some general comments:

    1. when you do "Build Player Content" it assumes it's building for a new player, so it creates a new catalog name. New content built this way will not be recognized by old players
    2. Prepare for content has missed some files. We think this is resolved in 0.6.7, but note, it is only needed if you have changes in Static=true groups. non-static groups will be ignored by the "prepare" step.
    3. Build for content update specifically names the catalog after the one that this older player is looking for. So you can update content.
    4. we've added a lot of docs around the update process with the latest release: https://docs.unity3d.com/Packages/c...manual/AddressableAssetsDevelopmentCycle.html


    if there are still issues, let me know.
    -Bill
     
  11. dbarile

    dbarile

    Joined:
    Apr 14, 2015
    Posts:
    11
    Thanks for your response Bill. Using Addressables 0.6.7, I just got a build working on Android, where a non-static remote content update worked as intended (schema set to cached).

    However, when I tried to do the same on iOS, it seems the device caches the Addessable assets. When I upload a content update, or even completely remove the iOS addressable folder from the server, the app still loads the original assets. Seems like a bug, but maybe I'm just missing something. Any ideas?
     
    johndis34 likes this.
  12. unity_bill

    unity_bill

    Unity Technologies

    Joined:
    Apr 11, 2017
    Posts:
    581
    I think this is our fault. When you do a build, it creates the content_state.bin file in Assets\AddressableAssetsData\addressables_content_state.bin. When you do an update, you build against that. The problem you're running into is:
    build ios -> creates content state
    build android -> overwrites content state
    update android -> so happy
    update ios -> looks at the content state based on that android build.

    This may not be exactly what you're running into, but it definitely feels like we aren't properly supporting multiple platforms. (this is known in some other areas as well).

    The probably work around until we get this fixed is to either use version control to manage your content state files, or to manually copy the file after each build somewhere safe.
     
    MNNoxMortem and johndis34 like this.
  13. johndis34

    johndis34

    Joined:
    Oct 16, 2012
    Posts:
    3
    I'm working with dbarile on the same issue. Is there any way possible to get a step by step solution for this work around soon. We are under a time crunch with this project and this is the last hurdle we have before sending it out.
     
  14. dbarile

    dbarile

    Joined:
    Apr 14, 2015
    Posts:
    11
    Thanks for your response, @unity_bill. Based on what you said, @johndis34 and I deleted the addressables_content_state.bin file just to be sure and ran the whole build, update content process, and iOS had the same caching/not updating issue as before. (To be clear, we are not really trying to build to Android and iOS, I just didn't have an iOS device, so I tried and Android build, and lo and behold, it worked properly, where iOS has been failing consistently in all our prior tests).

    I guess please note it as a Unity bug, unless there's something else we're not seeing here. We'll be awaiting the next update with baited breath.

    Another big request is the ability to set the RemoteLoadPath from code. Currently we are loading a bunch of assets from an array as a workaround, but the preferred method would be just pass in a unique server URL for each asset.

    Thanks so much!
     
  15. jmkearne

    jmkearne

    Joined:
    Dec 14, 2018
    Posts:
    1
    @dbarile If you don't mind, would you be able to share your project or at least the settings? I've been trying to get the same process set up for a while now and can't really get it right.
     
  16. unity_bill

    unity_bill

    Unity Technologies

    Joined:
    Apr 11, 2017
    Posts:
    581
    If you could file this as a bug from within the editor, that would really help (with a project, because this is not proving straightforward to repro).

    Do you need a unique URL per asset or per group? There are currently two ways to handle this. If you need it per group, you can use a variable in your load path with {}. (you can see that in how we do `{UnityEngine.AddressableAssets.Addressables.RuntimePath}`). This variable needs to be defined before Addressables initializes, and will be evaluated during catalog load.
    If you need to do it per asset, you probably want a custom provider. Today the `AssetBundleProvider` takes the passed in URL and does a web request on it. You could make a custom provider that takes that URL, mucks with it, then does the request. I think you could do this by inheriting from `AssetBundleProvider` but I'm not totally sure of that.
     
    MNNoxMortem likes this.
  17. dbarile

    dbarile

    Joined:
    Apr 14, 2015
    Posts:
    11
    Thanks @unity_bill We got it working! It seems the new version of Addressables fixed the issue. I'm pretty sure it has something to do with the fact that the addressables_content_state.bin file has been broken into two files, one in an /iOS folder and one in /Android. Whew! Thanks again for your help. We can finally move forward with the project.
     
    unity_bill likes this.