Asset Bin renaming operation = very slow

I need to rename some folders and files in the asset bin because the names contain spaces and periods which may become problematic when moving the assets into PerForce.

To update all paths and references, the renaming has to be done in Studio. When you rename a folder, all wav files in that folder will also neet to get their metadata updated.

However, this operation seems really, really slow. When a folder is renamed, Studio will freeze and ‘hourglass’ for several minutes or more without any indication that it’s doing something (except new files appearing in the PerForce changelist). Then it activates briefly, only to freeze again for a second delay equally long as the previous.

Why are these multi-file PerForce operations so slow to do in Studio?

A progress indicator would be helpful here. A dialog that shows the current file / P4 operation. Then you could verify that it’s still progressing and not just frozen.

In its current state (FMOD Studio 1.10.) it just freezes so that Windows even greys the window out as “Not Responding”. It does finish eventually, but it really looks like it’s crashed / frozen.

It just got worse… FMOD Studio actually did freeze and crash during a long folder tree rename operation, and now half the files (in random order) are in a new rename-copied tree and half are not, with “Missing File” reported on all of them.

This is not good… how on Earth will I fix this mess now, except manually, one by one, with a long delay with each one-by-one operation, since those changes were also done on disc. Oh, the frustration.

I was able to fix the mess by reverting my changelist, doing a “repair path conflicts” and starting over. Now the slow renaming operation (this is taking days) will continue.

I’ve added an item to our feature/improvement changelist to better handle long rename operations by displaying a progress bar and preventing the UI from appearing to stop responding. We’ll also investigate ways of optimizing bulk metadata changes of this type.

There is no method of repairing the damage done by the crash that’s more effective than the one you used.

More recent versions of FMOD Studio 1.10.xx than the one you’re using handle this kind of operation differently, by updating each individual asset file in perforce and updating its corresponding metadata before moving on to the next asset file. As a result, if a crash similar to the one you experienced occurs in one of these later versions, it results in fewer assets ending up with paths that don’t match their metadata, and is thus easier to fix and recover from.

Thank you for the response.

The crash is possibly related to the fact I left and locked my workstation (Windows 10) while it was in the middle of a long rename / move operation. Maybe the locking did something to the write permissions of FMOD studio. Just guessing here.

A programmer looked at FMOD Studio renaming a folder tree and was thinking that it could be possible to come up with a script that renames files and folders, and at the same pass updates the path references in the metadata XML files (while handling PerForce as well). But as for who would have the time to do it and when, is another story.

Side note: if you rename the base of a folder tree in the asset folder, the original folder will remain as a tree of empty folders. The wavs are moved to a new tree, but the original folders are left behind empty, then added to the assets as new folders. I’ll have to delete this empty folder tree after every rename operation.

Thank you for the information. We’ll investigate the effects locking a Windows 10 PC has on an ongoing Perforce/FMOD Studio operation.

This is the expected behavior. When renaming a folder in a project that uses our Perforce integration, FMOD Studio automatically invokes Perforce’s “move/rename” command for each of the files in that folder. Using Perforce’s operation, instead of moving the files normally and then updating Perforce separately, reduces the chance of errors and project invalidities being introduced in the event of an unexpected interruption to an operation (such as the crash you experienced). Perforce’s move/rename operation only directly changes the paths of individual files and creates new folders instead of renaming existing ones, in order to ensure the paths of files not currently in the user’s workspace remain consistent for other users using the same repository.

I just renamed a base folder that contains multiple subfolders with multiple wav files in each. I watched the operation happen in SpaceSniffer. First it was creating new files and moving wav files into those one at a time, at a rate of maybe one file per second (with hundreds of files, this will take some time). Then it froze for a few minutes and I could see new xml files getting checked out and appearing in the PerForce changelist (slowly, but still).

After this Studio just inexplicably froze for several minutes. I didn’t see anything happening on disc (SpaceSniffer) or in PerForce. What is happening during this time?

Yesterday when this happened, Studio also started taking 100% CPU, as if it had been stuck in a loop. At that point I just killed the Studio process. No changes were lost.

It seems, overall, much slower than PerForce Visual Client, NotePad++ (for xml changes) or the file explorer would take to move files, update metadata and check them out in P4. Why is Studio doing it so slowly?

Side note: the assets being moved are still outside the PerForce depot - the tree is getting cleaned up until it’s time to check them all into the depot under the studio project’s Asset folder.

What happens in Studio is that a tree of empty folders is left behind after the move, and Studio Assets is unaware of it - it doesn’t appear in the Assets so that the empty folders could be deleted. But they can’t be deleted with File Explorer either because Studio still has file permission handles in them somehow. So I have to quit Studio, delete the empty folder tree, then restart Studio. Seems like a bug. Or, if Studio gave an option to refresh / scan the location to see if there are files there it’s not aware of.

This issue was fixed in FMOD Studio version 1.10.06.

Our records suggest you’re still using FMOD Studio version 1.10.04. Have you considered updating to a more recent version, perhaps 1.10.15? It includes fixes and improvements that address most of the issues you’ve mentioned in this thread, and the banks it produces are fully compatible with the version of FMOD Studio that you’re already using.