Hello,
We are using addressable with FMOD. When we make a manual build it’s working well but when building on Unity Cloud Build (UCB). It seems that the addressable build do not convert the stub banks into real banks data because the final size of the addressable group is too small. And at runtime I have this error:
Error Unity BankLoadException: [FMOD] Could not load bank ‘Master’ : ERR_FORMAT : Unsupported file or audio format.
Maybe PostDependencyCallback and PostWritingCallback are not working properly for a reason with UCB?
I also had the issues with manual build on Mac the first time I build it. But it generated it correctly the second time without a reason.
Do you have a solution or an idea for this?
Or is it possible to force to build with some lines of code the real bank data to replace the stubs?
Unity version: 2021.3.2f1
Addressable version: 1.19.19 (I tried with 1.21.1)
Fmod version: v2.02.09
Thanks in advance
Ok I solved it. We build Addressables with UCB settings, so they were pre build outside the normal build process that fmod is registered by default. So the stub were not replaced at the correct time. We added EventManager.CopyToStreamingAssets(buildTarget)
and EventManager.UpdateBankStubAssets(buildTarget) to make it work for UCB.
At which point in the process do you do those two calls if I may ask?
Do you call both before building addressables?
To make addressables build, the RefreshBanks() call is vital in batchmode so maybe that should be added to the Addressables documentation
Debug.Log("FMOD: Refresh banks");
EventManager.RefreshBanks();
Debug.Log("FMOD: copy to Streaming assets");
BuildTarget buildTarget = EditorUserBuildSettings.activeBuildTarget;
EventManager.CopyToStreamingAssets(buildTarget);
AddressableAssetSettings.BuildPlayerContent(out AddressablesPlayerBuildResult result);
Debug.Log("FMOD: Building bankStub assets");
EventManager.UpdateBankStubAssets(buildTarget);
Thanks to for pointing this out @UncommonGames and @CineTek - glad to hear you managed to find a workaround. I’ve passed your information along to the dev team to investigate further.
I’ve traced the problem (I’m using cloud build with game-ci)
BuildStatusWatcher.Startup()
doesn’t call during cloud build, so bank stubs aren’t replaced with real assets, because event of addressables build isn’t caught properly by fmod.
I’ve tried to move this setup call from:
EditorUtils.CallStartupMethodsWhenReady()
to:
EditorUtils.Startup()
And this fix cloud build.
I don’t know how it should work but the fact:
- unity rise build event
- fmod editor utils hasn’t subscribed at that moment it occurs
1 Like
Thanks for providing some more info, I’ve passed this along to the dev team as well.
@UncommonGames
I’m having an issue with Fmod at the moment. Part of the issue might be related to the docker image I’m using.
Could you maybe share for which platform were you building?
@Maligan which game-ci image did you use?
Thanks
Hi,
I can see that your issue appears to have been handled in another thread: Docker Windows “DllNotFoundException: fmodstudioL” - #13 by megaleon
Can you please confirm whether your issue has been resolved?
Yes the issue is being handle in other thread.
I just wanted to check weather this was a only Windows issue… which seems to be.
We actually had to switch from AssetBundles to Addressables and we are facing exactly this same issue. What @Maligan states is right the BuildStatusWatcher.Startup() is not being called if you build using batchmode.
My solution was the following as prestep before the build
Debug.Log("FMOD: Refresh banks");
FMODUnity.EventManager.RefreshBanks();
Debug.Log("FMOD: copy to Streaming assets");
FMODUnity.EventManager.CopyToStreamingAssets(target);
Debug.Log("FMOD: Building bankStub assets");
FMODUnity.EventManager.UpdateBankStubAssets(target);
if(Application.isBatchMode)
{
FMODUnity.BuildStatusWatcher.Startup();
}
Thanks for the update, and for posting your workaround for other users. For some context, from your other posts it seems that you’re using 2.02.13 - the issue with BuildStatusWatcher.Startup()
was fixed in 2.02.15. That said, I’m happy to hear that you’ve managed to resolve problem.