We are using a shared network drive to contain the .wav assets of some of our game projects, instead of adding those wavs into our PerForce depot (file size policy). Due to several iterations, there is now a large number of #unused metadata xml files in the project’s Asset Bin.
I’d now need to Package the entire project including the audio assets, but it turns out the packaging also packs all the #unused assets, which in turn makes the package size exceed 4 GB, which apparently causes the package operation fail with an error even if there is disk space available.
I would like to delete the xml files referring to #unused wavs, but I want to keep the wavs (sometimes we need to go back on some iterations), to make the project package smaller.
Could you provide a script that can be used to delete the metadata xml files of #unused audio assets without deleting the .wav files on disc? Essentially, to “un-import” these files.
This would likely also make the project open a lot faster since there are literally thousands of #unused assets in the project by now.
Deleting a metadata file via script is beyond the intended scope of our scripting API, as our scripting API is not designed to support manual deletion or editing of xml files on disk. As such, we are unable to provide code-level support for this issue at this time.
At present, the only supported means of un-importing an audio file in FMOD Studio (and thus deleting the asset metadata) is to delete that audio file in FMOD Studio’s audio bin. This also deletes the asset binary file from the project’s assets directory, as you have observed.
The easiest solution may be to create a backup of your shared audio asset directory, delete all unused assets in FMOD Studio’s audio bin, create your package, then re-add the deleted audio files to the asset directory outside of FMOD Studio so that new metadata files are not created for the re-added files.
For future projects, we recommend using different asset directories for different FMOD Studio projects. Using a single directory for multiple different projects, even if they’re different versions of the same project, makes this particular issue unavoidable.
Very well, thank you for the suggestion. I’ll copy the entire folder tree to a backup, delete everything #unused, then copy back the wavs that got deleted.
We’re already doing this. All projects are on the same network drive, but each project is in a different folder tree (and the Studio project points to the specific tree, not the whole drive). A large number of #unused files will still end up existing, and we may want to use them later (for example, music cues that were initially scoped out, turn out useful later).
It would be good to have a “don’t include unused audio assets” option in the Package Project feature.
I have now purged the metadata files. There were a bit over 15000 metadata files, and only about 6000 of them were used in the game, the rest were all #unused. The project now opens faster, and also running our sound bank build batch is faster as it loads the whole project to build the sound banks, including all the unused files.
I could not do the purge in one go. When I tried selecting all the ~10000 #unused files and deleting them, the operation took about an hour, and then saving those changes took another hour but froze at the end, stopping at about 8000 files, not marking them for delete in PerForce. I had to shut down Studio and start over, then do it in batches of about 300-500 at a time. Which took pretty much the rest of the day.
Studio seems rather slow with PerForce, especially when a larger number of files is involved. But also overall.
When I tried selecting all the ~10000 #unused files and deleting them, the operation took about an hour, and then saving those changes took another hour but froze at the end, stopping at about 8000 files, not marking them for delete in PerForce.
I’ll investigate the slowness and freezing issues. Are you using the “Perforce” source control integration or “Perforce (Legacy Integration)” source control integration?
I was using the newer “Perforce” sound control integration.
The Perforce slowness I’ve been observing in Studio usually happens if you import a large number of wav files (which creates a large number of metadata files and marks them for add). After the initial operation delay, it seems to be followed by another long delay during which nothing seems to happen.
The P4v visual client itself seems to do these operations much faster than Studio (I know the recommendation is to do all the Studio PerForce operations through Studio itself).
When submitting your changes, the earlier versions seemed to go through the “saving changes”, “syncing latest” and other motions multiple times over, but this seems to have improved in the newest versions.