One thing that would help create clarity and confidence is to know what the test setups look these days for new releases. Are new versions mostly tested in ‘small lab’ setups and ‘small projects’ - aka single workstations, or maybe two workstations sharing storage? Are we’re relying on the beta testers for the big studio coverage (not realistic!)? Does the ADSK team have at least one setup similar to what you describe to stress test larger / complex setups?
Given that this is critical to key users, one would hope.
I realize that this is a non-trivial undertaking to simulate such use cases, but with an investment into test automation it is certainly doable.
Especially since ADSK is so hard-nosed about ‘you have to use a certified config’, which should in turn simplify the matrix rather than leave it wide open.
It would be convenient to report the issues you are experiencing so we could help.
By the way, are you using Gnome or KDE Desktop environment?
In the past, similar issues were reported in non compliant systems (ie non certified Desktop Environments like KDE).
BTW Flame has never been compatible at project level forward, just in service packs, so you are able to open a 2026.2.1 project from 2026.2.0 but you cannot open a 2026.2 project from 2026.1.
Have you updated our Support team with this information?
What you have written pretty much mimics what we have also seen in our lab looking at your project data but were trying hard to replicate the slowdown you got. Will you rebuild a new macOS workstation and see if you still get the issue? That could be a a good test. Ideally, you would preserve the legacy macOS config where the issue can be seen and see what are the differences.
Na, we do not “mac-mini” and ship bad software. We are not like that.
Software being software, there might be defects and behaviors based on configurations and workflows and we are more than open to help. This is why we have a great Support team and the development team is working hard to provide fixes. But for that we need your help. Please share your ticket number(s) with me so I can follow up about the issues you have raised with Flame 2026.x
As far as the documentation, many studios have follow the configuration chapters and successfully enabled work group workflows. Everything can be improved and I am looking forward to know more about your issues and suggestions.
You had two tickets: the one related to the current conversion / issue is still opened.
Please work with the Support team to help them replicate the issue OR investigate on your workstation to se if there is something fishy. We need data to help.
You can have access to the machine when ever. But someone from support needs to contact me to say hey we need something from you otherwise how do I know.
Because the ticket regarding my Linux woes was closed by support for inaction and had nothing to do with the still open ticket regarding the Mac.
Again. You can access that machine pretty much whenever you want, you just need to tell me. No one from support has communicated that you’re at a standstill and sadly I can only read agency creative’s minds.
Please use 25504564 which is the ticket for the current issue. After some days of inactivity I guess ticket gets closed. Then you will be able to coordinate with the Support team a moment when they can work with you on the case.
I just got a mail saying they want to close, again for inactivity. If you need something from me someone needs to ask. If you or support are at a standstill but you don’t communicate that what am I supposed to do?
Support had access to the box for a few hours and tweaked things. I’m going to archive back in the full project in question and test when I have some time of the next couple days.
Anecdotally, with what I have in Flame on that machine, the issues don’t seem to be present, but I need a project at scale to know for certain.
As far as what was fixed or tweaked, support knows and when this is all done it would be great to know if it was the project or the config or what.
@Slabrie Latest from support who beat the machine to the ground today:
The issue was intermittent and presented as long delays during project load and on application exit. Your smaller projects, long with the test projects I created, did not show the same behavior. The delay seems to occur between project load and Batch initialization. So might not affect the smaller projects due to smaller to no batch to load.
While digging through the affected projects via a test project, disk access and file navigation were within my expectations. No beachballing in the GUI. The timing of the startup delays did line up with activity in the debug logs, so I’ve marked that for review.
I can add, that operations like copying and pasting edits from reels in one library to another can also cause persistent beach balling. Having a couple batch groups open on the desktop also greatly magnifies the issue as well. None of the smaller projects are remotely the scope that I tend to deal with really. I can’t constantly be removing everything from the desktop to not be affected either. Also, managing projects of this size was never an issue in 2025 so I definitely hope that you guys can figure out what’s happening together.