Accelerator not working for some assets

Hello,

I have been trying to update a project to 2019.3, use the database v2 and setup an accelerator.
It is somewhat working but some assets either don't get stored on the cache (or get purged quickly?).

To verify that the cache is working as expected, after opening the project once and letting the Library build, I deleted the Library folder and started unity back again. It was much slower than expected, some objects (mostly FBX seem to be rebuild each time)

Looking in the editor log I see some assets being downloaded, but many others being rebuilt and re-uploaded to the cache.

For example below is an extract of the log file when opening the project after deleting the Library

Start importing Assets/Plugins/MecanimEventEditor/Example/Animations/Clips/DefaultAvatar@RunForward_NtrlFaceFwd.fbx using Guid(1cb8ed3cbba15f0479fbae54e0a963df) Importer(-1,00000000000000000000000000000000)
File 'DefaultAvatar@RunForward_NtrlFaceFwd' has rig import warnings. See Import Messages in Rig Import Tab for more details.

(Filename: C:\buildslave\unity\build\Modules/AssetPipelineEditor/Public/ModelImporting/ModelImporter.cpp Line: 3806)

Done importing asset: 'Assets/Plugins/MecanimEventEditor/Example/Animations/Clips/DefaultAvatar@RunForward_NtrlFaceFwd.fbx' (target hash: '2a16649bf8df532e18c66aa9c8f5ad6e') in 37.487763 seconds
RemoteAssetCache::AddArtifactToCacheServer - artifactKey='Guid(1cb8ed3cbba15f0479fbae54e0a963df) Importer(-1,00000000000000000000000000000000)' Target hash='2a16649bf8df532e18c66aa9c8f5ad6e'
RemoteAssetCache - Download - Metadata - success:true, namespace:81e94844d19a16919208533e08183531, key:7a3af252647a99ddc964732a5e3c5d06
​

If I delete the Library again I get this in the log

Start importing Assets/Plugins/MecanimEventEditor/Example/Animations/Clips/DefaultAvatar@RunForward_NtrlFaceFwd.fbx using Guid(1cb8ed3cbba15f0479fbae54e0a963df) Importer(-1,00000000000000000000000000000000)
File 'DefaultAvatar@RunForward_NtrlFaceFwd' has rig import warnings. See Import Messages in Rig Import Tab for more details.

(Filename: C:\buildslave\unity\build\Modules/AssetPipelineEditor/Public/ModelImporting/ModelImporter.cpp Line: 3806)

Done importing asset: 'Assets/Plugins/MecanimEventEditor/Example/Animations/Clips/DefaultAvatar@RunForward_NtrlFaceFwd.fbx' (target hash: '2a16649bf8df532e18c66aa9c8f5ad6e') in 37.487763 seconds
RemoteAssetCache::AddArtifactToCacheServer - artifactKey='Guid(1cb8ed3cbba15f0479fbae54e0a963df) Importer(-1,00000000000000000000000000000000)' Target hash='2a16649bf8df532e18c66aa9c8f5ad6e'
RemoteAssetCache - Download - Metadata - success:true, namespace:81e94844d19a16919208533e08183531, key:7a3af252647a99ddc964732a5e3c5d06​

Note that the hashes are the same but somehow the asset was not downloaded but was instead added again. Recreating the library takes well over an hour when I expected it to take a few minutes with the assets cached.

A thing to note is that I see the disk space used by the accelerator seems to hover around 10GB and not going over. I was wondering if it was flushing assets. There is over 1TB of free space on the disk.

Is there something I can do to improve that? The old cache server did not seem to do that, recreating the Library was around 10-20min.

Thanks

 

Small update. The problem does not seem to be related to the Accelerator itself, I was able to reproduce the issue with the asset database V1 and a cache server.

I will need to do more testing but it seems to be related to the newest URP.
Somehow with "com.unity.render-pipelines.universal": "7.1.8", FBX are cached properly. But with "com.unity.render-pipelines.universal": "7.2.0", FBX are re-added to the cache every time the library is recreated.

I went back to 7.1.8 for now and do more testing.

 

For those whom may stumble into this thread. I have posted in the URP forum.

https://forum.unity.com/threads/whats-new-in-7-2-0.827925/#post-5488611

 

I've contacted the team that owns this package and they are actively investigating this issue. No timeline on a fix, unfortunately, but they are definitely digging into it.