1.1.4 Cannot Build Player Content

I have been using Addressables through many versions of the Addressables package as well as Unity.
It worked great up to and including 0.5.3.
Any attempt to update the Addressables package beyond 0.5.3 resulted in the same problem:
When I run Build Player Content, it runs until it says Write Serialized Files, at which point it freezes.
The task manager shows that Unity is using 48GB of ram and 5% of the processor when it is frozen, so it seems to be doing something.
I cannot see anywhere on the HDD that it is actually writing the files, it appears that it created them in RAM and then is not able to write them to disk.

I know that there were breaking changes for the update to 0.5.4 about the locations for build and load paths, but I have followed that migration, and I have even used the various settings files and scripts from the Addressables sample which is built for 1.1.3.

I still think it has something to do with the target paths, but it all looks okay to me.
There is no info in the logs, it just sits there saying that it is Write Serialized Files with nothing actually happening anywhere.

Any thoughts about what could cause this? What else, besides the load and build path syntax has changed since 0.5.3?

Thanks,
-mat

 

I should add that I am using Unity 2019.1.8f1, however, I have been unable to build the packed content with the same freeze point in multiple versions of Unity, whenever I use a version of Addressables beyond version 0.5.3.

With the code changes, it is also getting a bit difficult to roll back to 0.5.3 and I would really like to get 1.1.4 working. The game runs fine in the editor, it is just the Write Serialized Files part of the Build Player Content that does not complete.

Also the Analyze feature of the Addressables package runs perfectly fine as well. Same with all of the steps leading up to the write, so the shaders compile and the asset dependencies are all checked.

 

Please file a bug against Unity with a repro project. Also, I do not expect things to work if you upgrade directly from 0.5.x to 1.1.x. We have some data upgrade/conversion logic in the package, but not for that large of a jump. You might need to upgrade from 0.5.x to 0.6.x and so on. Either way, with a repro project we can look into it on our end.

 

I just did a complete rebuild of the addressables package. So I removed it along with the scriptable build pipeline package, deleted the Library folder and all other project instances, reimported, reinstalled the Addressables package, reset up my asset groups, and now I think I know what the problem is...

When I mark a large asset file as Addressable, it will not build. It will lock up for more than an hour and eventually fail with an I/O exception, Stream Too Long.
It has nothing to do with how many files are in an asset group, just the presence of a file over a certain size.
In my case, this is just a 30MB FBX file, which is not unheard of since an FBX file is a container that can have many objects in it. I have a handful of large FBX files, so I am about to dial in on exactly what that size limit is.

This issue did not exist in 0.5.3, before the scriptable build pipeline dependency, as I have had these same files as addressable assets at that point and they packed just fine. In fact, I also have a 70MB FBX that works fine in 0.5.3.

A post from yesterday in the Addressables Are Here thread shows someone else with the same problem.

If I mark 4x ~8MB FBX files as Addressable, the build works. So the issue is with single files larger than a size somewhere between 8MB and 30MB.

To reproduce this bug, simply import a large FBX file with a lot of meshes, mark it as addressable and Build Player Content.
I can create a special project to do this and post a bug report, but it will take me a few days, and my complete existing project seems to be too big for the crash reporter to post without hanging after more than an hour of attempted uploading.
I will do it, but I think you should have enough to go on to at least look into it.

In the meantime, would it help if I just post a large FBX file?
-mat

 

Yes, it was me with that issue in the main thread. In my case though it happens when I have a bundle with a lot of small assets in them, like materials and basic scriptable objects/scriptable objects that reference assets from other bundles. It is most definitely a problem.

 

Yeah, I just tried a large image file and it worked fine, so this all makes it seem like it is related to the quantity of individual assets that it is trying to pack (directly or as dependencies) and it is treating an FBX file as a collection of individual assets.

Another counter, index, or file pointer with not enough bits perhaps?

 

I created a very clear project that reproduces this problem and filed it with the Unity bug tracker.
It is a completely empty project with just the Addressables package installed with its dependencies.
I added one somewhat large FBX file to the assets.
If that file is marked as addressable, the build player content fails after a long time with the stream too long exception. If it is not marked as addressable, it works as expected.

This exact FBX file packed fine up until Addressables 0.5.3.

 

I can confirm that this bug still exists in 1.1.5 starting with a completely empty default project. Building the player content hangs and fails with the addition of just one large FBX collection of meshes.

And it has been almost 3 weeks since i submitted the bug report. There has been no action on it. I would have thought that the bug posts would have been at least reviewed before a package comes out of preview.

 

What is the ticket number? The bug process can take time, especially over the summer months, but if you tell me the number, I can make sure we're looking closely at it.
Thanks

 

The bug ticket number is 1166277.

 

Wow, Thanks!
It would definitely be useful to have a code snippet that can create a single path entry to a large container asset in the scriptable build pipeline. I assume that I can create a copy of the current build script, add this code snippet to it, but selectively apply that build script to the asset groups that have these large container files in it?

In case it helps, my workaround for this problem has been to first re-export the meshes from max in multiple smaller FBX files (duh), then i have not been using addressables, just the standard asset bundles. And I only put the prefabs that use the meshes from the FBX files into those asset bundles so they pull in the dependencies. The bundles pack quickly and the build times are acceptable, and it does not hang.
But if I understand your post correctly, it is the separation of the FBX into smaller files that fixes the problem because the issue still exists in the standard build pipeline.

While I don't plan on going back to the giant single FBX files since I have split them all up, I still would want to get back to using addressables and the ability to create a single entry path for a collection would speed up packing and building and in my use case I never needed the individual paths to the mesh files anyway.

Thanks again!
-mat