I’ve been working on a long term project, and upgraded to 2026 a few months ago. Is it me, or does take MUCH longer to Save a Batch, or a Workspace? It’s fairly large - 100ish media clips, 25 Batches, 40 sequences, but the Batches aren’t terribly complicated - maybe 30-40 noes per Batch, but the saves are super slow… I never timed it before, but I’d guess 10 seconds? Now it’s 65 seconds every auto-save of the workspace!
I’ve seen some other threads about removing all old versions of Flame - is that recommended? I’m already “over the falls” on this one, so there’s no going back to 2025, but I’m also not super Terminal friendly, so I don’t relish copy-pasting commands I don’t understand…
I have not had this experience, although I have removed all traces of 2025 from the system. One thing I have noticed is that my 2026 archives open and close much faster than the 2025 archives. And by that, I mean the 2025 archives when I was still running 2025.
100% Agree, most of the time. I was thrilled to have a new type tool, LOL. But seriously, there’s a lot of animated text, so working in that old Text tool was a major pain point for me. WAY worse than having slow saves.
@davejahns - hardware RAID5 is normally set to a fixed block size.
writing many small files into large blocks is inefficient.
when you get round to it, consider using a mirrored z-raid with unspecified block size.
do not use hardware raid controllers.
also, read about sync and async and RAID5 write holes.
Having this same issue in 2026.1. Project gets to a certain size and the project becomes unusable. Loading workspace and autosave takes 3-5 minutes plus. Entering BFX the same.
I created a new project and wired the most need media across, but same issue persists.
Since the introduction of BFX I have used BFX and connected segments as my default workflow.
I’m on my second big show in 2026 and this problem has now made Flame unusable at this point.
I have extracted all BFX setups and converted to BatchGroups, but at this point it seems like the database is still the issue.
I’ll gather further info and post this to a new thread and post a ticket with Autodesk as well. (Funny how these things happens on the weekend and day of final delivery)
What storage are your projects stored on now? Same as stone+wire was before or different?
There are multiple paths in the project window. Media and project files are separate. They’re not super intuitive for their defaults, so worth making sure everything is on suitable hardware.
Storage is on the same Stone+Wire hardware and set manually to the correct path for that storage. Setups are on the default internal SSD of the MacStudio. I suspect that this issue is also tied to the BFX workflow getting to heavy at some point.
In some very rare instances, this might be a related issue, although it’s prevalence is in Windows environments, not macOS or Linux: ZSTD-22 is 30 times slower than it should be
We are seeing this horrid performance also.
I’ve been working with ADSK for about 6 months on a different critical failure bug in 2026.x that just got solved. I’ll start on them with this issue shortly. We may have to stick on 2025 for quite a bit longer.
Maybe a given but thought I still mentioned. Up until v2025.x, if I carried multiple batch iterations I’d experience minor to massive slowdowns while performing general lib/housekeeping tasks (saves, loads, moving/copying things around etc). The more the iterations, the more the slowdowns. Having minimum to no iterations brought things back to normal.
would this be your recommended way forward (reverting back to 2025)? I just had a very challenging client session on final delivery day of the above mentioned problematic project.
Please keep me posted on your findings. I would like to contribute to this process where possible. I just have not had time to gather more data on this current issue, while desperately trying to deliver this current project.
I’ll start gathering more information on the issues at hand and start building a case file.