CRC Mismatch

We're experiencing the same issue on iOS after upgrading the project from 2019.4.17f1 to 2020.3.11f1. Project uses unity CDN. We synced the entries to the same bucket with assets from older version, but we're using a new release with different badge.

 

I'm having this issue pop up occasionally as well. It doesn't happen in the editor with "Use Asset Database" enabled which is what I test on. But players are having it happen alot, and I've even had it happen a few times in the production version as well. I've had in happen on my WebGL build, but I think players are having it happen on all version (although I can't verify this yet.)

note: I'm using unity 2019.4.27f1 and Addressables verison 1.18.9.

 

Error is definitely happening on Windows standalone. I'm wondering if I'd just be better off disabling all of this CRC, as it seems to be irritating alot of players with having addressables downloads fail too often, forcing them to restart the game. I'm just not sure what the downsides to disabling it would be, and how likely those "downsides" are to happen.

Here is my error log for this. Simply reloading the game will generally allow it to work.

Error while downloading Asset Bundle: CRC Mismatch. Provided cb4de052, calculated 6660923 from data. Will not load AssetBundle 'https://eliatopia-files.s3.us-east-...n.png_679b56d0a199ade1d9c476409b9c27e7.bundle'
Curl error 23: Failed writing body (0 != 8579)

(Filename: Line: 831)

Web request failed, retrying (0/2)...
Unable to write data
ResponseCode : 200, Method : GET
url : https://eliatopia-files.s3.us-east-...n.png_679b56d0a199ade1d9c476409b9c27e7.bundle

UnityEngine.Logger:LogFormat(LogType, String, Object[])
UnityEngine.Debug:LogFormat(String, Object[])
UnityEngine.ResourceManagement.ResourceProviders.AssetBundleResource:WebRequestOperationCompleted(AsyncOperation)
System.Action`1:Invoke(T)
UnityEngine.AsyncOperation:InvokeCompletionEvent()

(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 39)

 

Encountered the same situation：
Error while downloading Asset Bundle: CRC Mismatch. Provided xxxxxxxx, calculated xxxxxxxx from data. Will not load AssetBundle 'XXX'

 

We also got "Error while downloading Asset Bundle: CRC Mismatch" with newly built content and a newly built player.

It seems to me that it should be impossible to get this if we build new content and a new player. We can't tell our users to go and clear the cache.

Unity 2020.3.15.f2
Addressables 1.18.11
Windows 10 64-bit

 

For anyone still wondering about this issue. I ran into this recently and found out a key issue that is most likely the reason for the CRC mismatch. If it's a bug or not I'm not sure. It would be nice to have confirmation from Unity if this is expected behavior or not. For context, I am currently on addressables version 1.10.0.

- When you build addressable content from scratch, bundles will be created, and a CRC will be generated for the asset bundles produced to inject in the catalog.

- If you build again without clearing the build cache, the cached asset bundle will be used to produce the catalog (CRC generation), and it will be the same (since it used the cached asset bundle).

- When you do clear the cache however, new bundles will be produced, and the CRC will change. I'm assuming there is a time stamp or something like this in the bundles which makes the CRC change. However, the hash will remain the same as the content of the bundle has not changed.

The asset bundle production is not part of addressable. Addressables simply invoke the build call that is part of the com.unity.scriptablebuildpipeline project.
The addressable build scripts call into the following.

Code (CSharp):

1.  
2. ContentPipeline.BuildAssetBundles(buildParams, new BundleBuildContent(m_AllBundleInputDefs), out results, buildTasks, aaContext, m_Log)
3.  

Which then produces build tasks

Code (CSharp):

1. class ArchiveAndCompressBundles : IBuildTask

to execute. This task handles caching/producing bundles and will simply fill a Result object with the data from the asset bundle build. This data is used by addressables to inject CRC/Hash in the catalog.

When not using the cahced bundles, the specific function that invokes the bundle builds is the following...

Code (CSharp):

1.  
2. UnityEditor.Build.Pipeline.Tasks.ArchiveAndCompressBundles.ArchiveSingleItem(...)
3. {
4. ...
5. item.ResultDetails.Crc = ContentBuildInterface.ArchiveAndCompress(item.ResourceFiles.ToArray(), writePath, item.Compression)
6. ...
7.  
8. }
9.  

My question to Unity is,

Is it normal that the

Code (CSharp):

1. ContentBuildInterface.ArchiveAndCompress(...)

call produce different CRC for the same asset bundle (producing same hash)?

In my tests, every time this runs for the same bundle/assets the produced CRC is different, but the hash is the same.

If you then re-use produced bundles from old addressable builds and rely on new catalogs with the same load paths, this will cause CRC mismatch if the catalog build did not have the cached bundles producing the original CRC. Since the new catalog produced will contain the same load path (same hash) but then have a different CRC (from the new bundle produced in the second build). This is problematic if you have a content build process outside player builds. It also means that even though you have bundles with the same hash produced, CRC could be different.

To Unity, is this expected behavior from

Code (CSharp):

1. ContentBuildInterface.ArchiveAndCompress(...)

? That the CRC returned is different for the same data?



UPDATE: I am noticing that the CRC changes only for certain bundles and not all when the cache is cleared. Will have to investigate further. I'm assuming that the answer to this question is NO. The CRC should be the same.

 

My previous post can be ignored.

Upon further investigation it appears it was something in our project hooking into the scriptable build pipeline and changing things which caused CRC to change but not the hash. This will for sure lead to CRC issues if the build cache is cleared. Therefore, I don't believe there is a bug here. If you encounter this, please double check that you don't have things hooked into the scriptable build pipeline and changing things in non-deterministic ways.

 

Just updated Unity 2019.4.29f1 --> 2019.4.35f1 and began having CRC mismatch errors related to the Localization package using Asset Bundles on WebGL.

I didn't upgrade my Localization or Addressables packages. Their versions are:
Localization: 1.0.0
Addressables: 1.19.4

As a temporary fix, I've disabled "Use Asset Bundle Cache" in my Group Settings. This seems to work for now, though it's far from ideal and I'd like to re-enable caching as soon as possible.

I assumed that the mismatch errors were a result of the Unity upgrade ("If an AssetBundle is built with identical content, but two different Unity versions, the hash will be the same, but the CRC will be different." -reference), but the errors continued even after adding new content to my Asset Bundles.

 

Processing Error, see Download Handler error : CRC Mismatch. Provided ba6d142e, calculated 3fcd5fff from data. Will not load AssetBundle

Just here to say.. yup this is still a problem in 2022.1.0b14

 

We just have this problem, and on our side, all the incidents happen to one bundle: unitybuiltinshaders.

Upgrading Unity from 2020 LTS to 2020 LTS, only a few patch version increased (from 24 to 33), tested with both Addressable 1.19.19 and 1.19.15. Both have the same issue.

Reproduce is, clear data, use old unity version build to load addressable package built from old unity version, then use new unity version, then load the same addressable package but built from new unity version, this issue will happen.
We're using Unity build-in shaders, no URP or HDRP used.

I can't create bug report, since all contents are not for public.

 

I am also having the same problem here with my Android build.
I built the addressables with my machine with Unity 2020.3.31f1,

UnityWebRequest result : DataProcessingError : Data Processing Error, see Download Handler error : CRC Mismatch. Provided b1cb81d3, calculated af87becc from data. Will not load AssetBundle 'this-is-my-temp-s3/Android/scenes-pack_scenes_all.bundle'

Did I set something wrong?

 

Could someone explain what is actually happening with this error and how to fix it? Please. Just rebuilt external addressables (1.18.9) and now game can't load them, throwing this error.

 

@unity_shane, any updates?

 

Hi @davidla_unity @unity_shane @pillakirsten. The current addressables 1.20.3 has crc mismatch issue for Update a Previous Build. If I remember correctly previous addressables version is working partially. Currently after Update a Previous Build, it failed to detect and update to new bundle and it just skip it. Then after clear the whole cache and restart game app again to redownload all the bundle, it will just spamming lots of crc mismatch error. Even worst thing is even I set Asset Bundle Cache to Disabled at Addressables Groups window, it still does not detect new bundle and update it when I open game app. I just doesn't work and I can't find any workaround.

 

Hello guys,
Our project was on unity 2019.4.16 and we upgraded to 2020.3.37 then 2020.3.39 and everything was perfect with no error.

because we moved from 2020 to 2019 and vice versa, I got the CRC errors on the editor but the current release on the store (Android and iOS) with no errors.

Android platform fixed with me by coincidence

First, I tried to increase the version of the catalog and upload the bundles to the server, but nothing worked. I reverted everything as before and it works, but I don't know why. I think fixed after uploading new files to the server

I tried the same thing on the iOS platform but nothing worked.

In the end, I tried to re-upload one bundle to check if it work or not, but, it works finally,

So I fixed the problem by re-uploading the bundles to our server.

 

Same Here

 

From my side, it came from upgrading from Unity 2020.3.34 to 2020.3.40. I first thought it had to do with my latest upgrade to 2021 but when I reverted to 2020.3.40, things were still broken. I am hoping that Unity will make a more stable asset format for maintaining live applications. Locking my content to a Unity version is an understandable yet tricky issue to deal with. RemoteConfig does come in handy here though for directing apps to use versions of assets.

 

Same here,
I was on 2019.4.16 then upgraded to 2020.3.37, and I was forced to work on both versions because we had a high ANR and Crash Rate because of version 2020.3.37.

Then the project on 2020.3.37 has broken from the addressable. so I upgraded again from 2019 to the same version of unity 2020. then it has broken.
And because of ANR and Crash Rates, we changed the plan to upgrade to unity 2020.3.34.

So after re-upgrade to 2020.3.34, the problem has gone, but it is back but not as before. (some times when I used the bundles on the Editor I got the CRC mismatch error) but on the store (Android and iOS) platforms, the error does not happen for now.

BTY, I'm using an addressable version 1.18.19

 

Hi, We have been building an App now and testing on Android as our Primary testing device with ZERO issues. But on IOS we seem to be getting CRC on every addressable that it tries to load from cache, restarting the app then fixes the issue and addressables start working, but this is such a weird error. Any ideas on why this is happening specifically on IOS?

 

This post might be helpful. The asset bundle headers contain the Unity version. Consequently, the CRCs won't match on different versions, even if nothing changed in serialization. There's an option to "Strip Unity Version From AssetBundles" in the addressables settings which might be helpful.

 

This appears to only happen when you are using custom catalog names that do not append the hash and are loading remotely via Google Cloud Platform. If the catalog you are trying to load has the same name as a previous catalog, Google Cloud Platform will attempt to load the old catalog which is in its cache. It can take an hour for the old catalog to be invalidated and for GCP to start using the new one.

Ideally, you shouldn't be building a new catalog, you should be updating the existing one and overwriting what you have on GCP Cloud Storage. Same name, same hash, updated content. Otherwise, you are getting the catalog of the same name but with a different hash which causes the CRC mismatch until the old file with the old hash gets invalidated and the new file with the same name but different hash propagates.