For a while Flame on my main system takes a long time to startup. It always pauses on ‘Project: Initializing’ for an extended period, and I’ve always assumed it was timing out something.
Today I saw an error message confirming that in the terminal:
Likely a hang-over from 2025 installs on that system when storage was still managed. And likely a 2025 project pointing to storage on my other Linux system, which is no longer around.
Not a big deal, except it’s not clear how to get rid of it, without wiping the system, which is not an option for a while due to existing jobs.
I’ve deleted all projects that are pre-2025, so there are no old projects sitting around. And all 2026 projects there is no more project config for framestore. So nothing to delete there.
In the setup app, there used to be a storage tab. But that no longer exists either.
So there doesn’t seem to be any UI left in 2026 to declutter this mess.
Anyone have any idea which of the config files this may live in, so I can chase it down and nuke it the hard way?
It’s not the end of the world. Just a minute of delay when starting Flame. A bird sneeze compared to the crap people go through with 2026 project server.
Spring time means Sprint cleanup!
The file /opt/Autodesk/sw/cfg/sw_framestore_map might contain information about your legacy workstation. This file is used by pre 2026 releases to map the various stone+wire volumes in your workgroup and is no more used with 2026 release. We still package all the stone+wire components with 2026 in case you need them on a new workstation that would also need to run pre 2026 release.but in your case, just edit the name of the file to add “_backup” and you should be good to go.
Let us know!
Thanks Stephane. I’ve looked at that file for a clue, but it doesn’t contain any active data other than the default entries.
I looked through all the files in /opt/Autodesk/log and I can see the error there. It does indicate it being sw related, but no further clue. And ‘id 2’ doesn’t give any context which framestore it may have been.
The hunt continues.
Monday AM challenges 
Have a look at the various configuration files in /opt/Autodesk/sw/cfg for any presence of the remote volume.
Also, could you try to delete the content of /opt/Autodesk/cache/slates/? Maybe there are some old slates referencing content on the legacy workstations that cause the issues.
1 Like
Thanks @Slabrie.
Finally found it. But was still different.
There were no old or stale files on my Linux machine. I checked every .cfg, cache, project folder.
However, on my Mac, there was an older version of 2025.2.2 still installed. And it had three framestore partitions configured, two of which still existed, and one which was on a disk that is no longer with us.
After removing the three framestore partitions from the sw config on the Mac, uninstalling the old 2025.2.2 version of Flame and deleting all old projects there, now on my Linux Flame it starts up quickly and I no longer see that error message.
So the Linux Flame somehow communicated with s+w on the Mac, even though Flame was not running there, and hadn’t been since the last reboot. Saw those frame stores, but couldn’t communicate with them. I guess s+w was alive enough to share config, but not alive enough to answer appropriately.
Problem solved on my end. But it seems like there’s some gremlin in how this behaves. That was multiple hops of debugging, and it’s not uncommon to have old stuff somewhere that has been long forgotten.
Very good!
It is normal that Flame communicated with your mac even if Flame was not running or even uninstalled. The moment a S+W host has been configured it is part of the workgroup and the error displayed was expected.
1 Like
