Search Unity

Resolved LoadContentCatalogAsync loads outdated information.

Discussion in 'Addressables' started by JonathanBartel, Apr 27, 2022.

  1. JonathanBartel

    JonathanBartel

    Joined:
    Jun 24, 2019
    Posts:
    47
    I've been using Addressables for several years now and haven't experienced this issue until recently. Though I couldn't say what version of Addressables I first noticed it, I believe it was 1.19.18 or 1.19.19. When I call Addressables.LoadContentCatalogAsync("path") it's loading old information from a catalog that no longer exists.

    A short example for more context, let's say I have two assets: AssetA and AssetB. I build the bundles with a hash appended to the name, so I get AssetA_111.bundle and AssetB_111.bundle. (Real hashes are generated. I've kept the hash simple in this example for readability.) I load the catalog at runtime; everything's fine. AssetA and AssetB load correctly. Then, I update AssetA and delete AssetB and rebuild. Now I have AssetA_222.bundle and no bundle for AssetB. When I load the catalog at runtime, it's looking for and can't find AssetA_111.bundle and AssetB_111.bundle (not surprising seeing as they no longer exist). When I open the catalog.json file in a code editor and search for AssetA, I can see that the catalog does indeed point to the new bundle (AssetA_222.bundle) and makes no reference to the old bundle or to AssetB. So if the catalog is built correctly, why does Addressables.LoadContentCatalogAsync("path") load outdated information?

    It seems like some sort of caching issue. I do call Addressables.ClearResourceLocators() before loading the catalog and I'm positive the provided string for the catalog path points to the correct location. I have "Use Asset Bundle Cache" unchecked in the settings. I've tried Addressables.ClearDependencyCacheAsync("key") which didn't help this issue. I've also tried Addressables.CheckForCatalogUpdates() but the list it returns has a Count == 0 and there is no change in behavior. This happens in the editor and in the build.

    Has anyone seen anything like this? Any suggestions?

    Code (CSharp):
    1.  
    2.     public static IEnumerator LoadCatalog(Action<LoadResult> callback)
    3.     {
    4.         Addressables.ClearResourceLocators();
    5.  
    6.         AsyncOperationHandle<IResourceLocator> loadCat;
    7.  
    8.         try
    9.         {
    10.             loadCat = Addressables.LoadContentCatalogAsync(GetCatalogPath(), false);
    11.         }
    12.         catch (Exception e)
    13.         {
    14.             Debug.LogError(e);
    15.             callback(LoadResult.CatalogError);
    16.             yield break;
    17.         }
    18.         while (!loadCat.IsDone) yield return null;
    19.  
    20.         if (loadCat.Status.Equals(AsyncOperationStatus.Failed))
    21.         {
    22.             callback(LoadResult.CatalogError);
    23.             yield break;
    24.         }
    25.  
    26.         Addressables.Release(loadCat);
    27.  
    28.         callback(LoadResult.Success);
    29.     }
     
    Last edited: Apr 27, 2022
  2. JonathanBartel

    JonathanBartel

    Joined:
    Jun 24, 2019
    Posts:
    47
    So this is interesting...

    In my persistent data path, there was a folder called com.unity.addressables which had dozens of what looked like cached catalogs. I noticed one of them was from as recent as today. I deleted this folder and now everything is working correctly. Huh? What would cause the creation of the folder and these cached catalogs?
     
  3. JonathanBartel

    JonathanBartel

    Joined:
    Jun 24, 2019
    Posts:
    47
    True to fashion, I struggle with something for days but then THE DAY I post my problem on the forum, I figure it out. This was not an issue with Addressables, but with a small change I made to my code. If you're from the future and you're running into this problem, too, read on for the answer.

    This is the solution to the best of my understanding. Apparently, the catalog.hash file that is built with the catalog.json file is actually important. I assumed that it was generated only for us, the programmers, to compare catalog versions and, while there's truth to that, apparently the Addressables system also relies on this file. When you load the catalog, Addressables caches the catalog and the hash in the com.unity.addressables folder. When the hash number in the catalog.hash document changes, it knows to refresh the cache. If the hash document that's with your catalog.json file is not present or never changes, it will never refresh the cache. In my case, it wasn't present because I chose to not download it from my server when updating the catalog (I didn't think it was necessary).

    #StupidMe. Hope this helps someone.
     
    tonemcbride likes this.