FMOD prompts for save on exit even when the project is saved

FMOD prompts for save on exit even when the project is saved. Not only that, once you exit, the program hangs open for several minutes.

This is 2.01.07 on MacOS.

I have tested out several projects in FMOD Studio 2.01.07 on macOS 10.15.3 without seeing this issue. Are you seeing the same problem if you use a new project?

No this doesn’t happen for an empty project. Just for our game project.

I wonder, does the system save things asynchronously and expect it to finish before you close the program? That seems like it might be what’s happening.

If hit save, and then try to close the project, it prompts me to save again and then takes a couple minutes to finish before it really does close. Note, when I say it takes a couple of minutes, I mean that the save progress bar finishes immediately, but that the program remains open until it actually finishes whatever it’s doing.

If I save the project, wait a couple minutes, and then try to close, then it closes immediately.

It sounds like one of your project elements is not saving correctly. When saving you should see a dialog of every element being saved before closing, it shouldn’t really be saving without this dialog. If the save dialog is not where you are experiencing the hang then could you please try the following:

  • Select File > Validate Project and note if any errors are thrown
  • Open Window > Console > Logging and then exit the project. When it hangs, are there any errors being thrown here?

Thanks for the steps! I’ve just tried both:

Validation yielded no errors.
Logging yielded nothing untoward. That said, you asked me to observe the logs while it hangs. It hangs after the windows have closed. It sits in the application tray for a minute or two before closing.

The other anomalous behavior I mentioned where it prompts me to save even if i’ve just saved yields no logs either.

I think it might be worth sharing this FMOD Studio project with us for further investigation. These behaviours are not to be expected with FMOD Studio and so far none of our diagnostics have given us a clue what’s happening.

Shoot, I’d really like to, but your company won’t sign an NDA. I really can’t hand over all the audio for the game like that.

I can make a video if that’s helpful? Is there anything else I can do on my end to provide you diagnostic information? Is there any way for me to monitor logs after the console has closed and the program is hanging? Can I tail the log file outside of the program?

Yes, if you please make a video with the following:

  • The hang as it normally happens
  • Display the asset browser (to see how large it is)
  • If possible, show the Activity Monitor when FMOD Studio is trying to close
  • Open ~/Library/Application Support/FMOD Studio/Logs and share the most recent log

Absolutely! I’ve uploaded the video and log file to my FMOD account here.

Incidentally, there’s another reproduction that hasn’t been looked at uploaded there if you have the time to share that with relevant devs. The file’s called and has to do with Cleaning up duplicate platform warning

Thank you for uploading the video. Straight away I can see that when you opened the Assets Browser it started to populate slowly. From the logs it shows that it is importing, creating XMLs for, and backing up all of these assets too. I believe this import/updating process is what’s causing your project to enter an “altered” state, prompting saving before closing, as well as what’s keeping the FMOD Studio process alive after closing the application.

Are these assets stored somewhere other than the local hard drive? For example, in an external hard drive or on a network? Or are these assets being affected by a third party backup software, such as Dropbox, Google Drive, or Time Machine?

Oh interesting! So the audio files are stored locally, but google drive backup and sync makes sure they’re synced in the cloud too.

So, as an experiment, I turned off backup and sync. Unfortunately, I seem to be experiencing the same behavior even without backup and sync turned on.

I tried waiting a few minutes on startup for all the assets to populate. If I do that, then FMOD quits as expected. However, the next time I open the program, the exact same thing happens. So maybe it’s the asset scanning that’s holding everything up? This is all on a local SSD.

Very interesting. If the audio files are local and not being locked by Google Drive, then something else must be going wrong. I’ve been able to replicate this slow population somewhat by placing a large amount of audio files into the asset folder on disk and deleting the AudioFile XMLs before opening the project.

Could you please open the project’s root folder in Finder then go to Metadata\AudioFile and see if there are any XML files in here? If there are, please perform the following steps with the FMOD Studio project closed:

  1. Create a backup of these XMLs by copying them into a separate folder away from the project’s directory.
  2. Open the FMOD Studio project and wait until it has finished doing…whatever it is that it’s doing and all the assets has loaded in the Assets Browser.
  3. Use a text diff tool such as Meld to compare two of the same files from the copied XMLs in step 1 to the current XMLs in step 2.

Again - please ensure you copy the XMLs, and not move them. Hopefully these two files can show some differences but if not we will search a bit deeper as to why these assets are so slow to show in the project.

Oh great! Glad to hear it reproduces.

I did as you suggested. My FMOD exists in a git repo so I just opened FMOD, waited for it to finish it’s important work, then closed it.

Git says nothing changed in any of the XML files after that.

Hmm, so the project itself is source controlled with git and the assets are backed up with Google Drive.

The issue is definitely being caused by the XMLs of the AudioFiles not remembering where these audio files actually are. Are you able to share just one of these AudioFiles XML with me to take a deeper look?

In the meantime, could you please try the following:

  • Copy the entire project to a different machine (Mac or Windows) and see if this same issue happens.
  • Are your assets in the default project location, or is there a different location listed in the “assets folder” property in Edit > Preferences > Assets.
  • Are the directories you have placed the assets in affected by any compression?
  • Is the FMOD project itself being backed up on Google Drive? The XML files themselves could be being locked when being accessed.

Sure thing! I’ve uploaded a zip called “FMOD XML” containing all of the xml files in that folder.

My assets are not in the default location, they are here:

They are not affected by any compression, no.

Nope, the FMOD project is not in google drive or dropbox. Just git.

I haven’t had time to try this on a different machine yet, but I’ll let you know if I get the chance.

I took a look into the XML files, thank you for providing them. Looking back on your original video I’d like to try one more thing:

  1. Open the FMOD Studio project and leave it for a few minutes to let it finish its process
  2. Once finished, open the Assets Browser and click the magnifying glass, selecting “Filter by Unimported assets” from the dropdown
  3. Click the “flatten” button at the bottom of the assets browser
  4. Select all assets (command & A) and right click > Import

Can you confirm that, after importing all of these assets, you are no longer getting this hanging/slow assets issue?

I just followed those steps, and FMOD became completely unresponsive for thirty minutes before showing a progress bar.

After the progress bar showed up, it took fourty-five minutes more (1h15m total), 40+ threads, and >50GB of ram to complete.

But now that it’s finished, it seems to be working! So that’s good! I’m not sure what this all means, but thank you for finding a solution.

What’s the guidance going forward in terms of workflow? Was I doing something wrong? What’s the significance of importing or not importing? Is this expected behavior?

Excellent! Then it was what I was expecting. I’ll give you a quick run down:

The reason FMOD Studio was slow was that it had an enormous amount of unimported assets. Unimported assets do not have XMLs saved. Once you open the project FMOD Studio will then generate an XML for each of these unimported assets and store them in the .unsaved folder in the project’s root directory. If you do not import these assets then it will delete all these XMLs upon closing the project. So each time you open, it’s generating a lot of XMLs, and each time the project is closed without importing, it’s deleting all of these XMLs.

When you properly import the assets then it will move all these XMLs into the project’s metadata folder. You do not need to save or wait for these processes to finish as the XMLs are now present. (I feel I have said XML so many times it’s lost all meaning).

This is technically the expected behaviour, but the system is not expecting a large number of unimported assets. We can look into improving this importing process for a future update, but in the meantime it is working as intended and you didn’t do anything wrong.

If you have any further questions, please feel free to ask.

Ah I see! So maybe the default behavior should be to import assets in the assets folder? I was totally unaware that import was necessary. In point of fact, the software works without importing, it just does this weird hanging behavior if you don’t (without warning or anything).

Thanks so much for figuring this one out!

The ideal way of importing assets is through the application UI, either by dragging & dropping files/folders into the Assets Browser or clicking File > Import Assets. When using either of these methods the assets are imported into the project by copying those files into the Assets directory and then their respective XMLs are generated.

If you manually move the audio files to the Assets folder on disk (eg. copy/cut and paste the audio files via Finder or Windows File Explorer) then FMOD Studio will detect the files are there but it won’t create the XMLs to know what to do with them until they are either used by an instrument or you right click and choose “Import”. It is by design not to do this automatically to avoid certain situations. I have raised a bug report to look into the performance of situations with lots of unimported assets.