…You go to make a library and have enough time to brew a pot of coffee.
Sigh.
Imagine if you were the 47th potus and you go to make a library but you can’t fit your Qatari jet through the front door…
Sighs matter…
and this is why we are still on 2025 in 2026. I have a feeling I’ll be saying that in 2027 too.
Sigh.
It’s the inconsistent “outta no where” and “near instantaneous” decline from working just fine to “I’m going to take a quick nap while this works it’s shit out” that catches me off-gaurd every time.
The parallels that can be drawn to the 47th potus continue…
Outta nowhere
Instantaneous decline
This would drive me nuts. I’m also on 2025.2.2 and it’s perfectly fine for the work I need to do.
is project located on local storage or network?
Local.
I’ve been tell them the Library operations are multiple times slower in 2026+ than in 2025. In another forum there is a claim that a newer version is 30% faster in Library ops.
Meanwhile
Shit gun is appallingly slow.
There are many reasons.
All of which sound like “dog ate my homework…”
Life is short.
This stuff is ultimately meaningless…
(And if it were not reality would be different)
Move on.
Make money.
Blaze the trails.
Climb a mountain like @ALan
Having suffered through this and tried some things, I’m convinced the most performant way to run Flame now is to keep batch groups out of the libraries completely. Off the desktop too of course, other than the hot ones. The library structure, it turns out, can be replaced by whatever you decide to build as a harness externally- think of it like working super-unmanaged.
In my case, it happens that I had built some hooks and GUIs to make loading and iterating batches nicer and more standardized- since I’ve adopted an odd workflow with 4 sequential batch groups per-shot (i.e. ‘prep > comp > color > master’, I wanted code that managed these batches properly across multiple workstations. It just so happens for me that this workflow is much more performant! A happy accident.
With hooks, Flame workstations can just save out their iterations to local NVME, and then these saves can be rsynced to the studio NAS in the background. Whatever state machine you have working, then picks up on it and can list it as the most recent version to an artist opening the batch loader GUI on another station. Minimized nfs overhead, no project server overhead, and you can customize it precisely to your needs. Logik Projekt I think is the core, and any custom code that can run in the background will run circles around whatever happens in libraries.
This mirrors what I was considering today. Basically a loader for batches which exists outside the fold of the flame workspace.
I actually hate the desktop. I always have. That batch groups exist there break this critical boundary in my mind between effects and editorial organization… and this relentless bloat and slowness it all takes on just foments my position.
Sigh. Tomorrow I’ll crack open Claudex.
Such an insidious and maddening situation…
I had to fight one of these a few weeks ago. Took 18hrs to track down and give the devs the precise root cause, including totally tearing down the system, and a few false positives.
In their defense, they were very helpful throughout the process. It caused Flame to crash hard under very specific circumstances. They ran my setup and it didn’t crash for them, same system config, but small environmental difference.
It is now fixed in whatever the next version will be. Finding it required attaching with the debugger to the Flame process and trapping OS events and logs.
The situation you describe hasn’t happened on my system, so I can’t be of much help here.
But if one were inclined, these would be a few things worth looking at:
- Establish if Flame is I/O or CPU bound during this time, and whether it is single-core or multi-core-bound if so. That would tell us if the inefficiency is files, or an algorithm doing some project file maintenance that bogs down. You could do that with some basic bash script that logs data every 5s into a file.
- Find out which files it’s occupying itself with. Similarly, use a bash script that makes a folder/file list snapshot every 10s into a log file, that then can be diffed.
- Monitor other OS stats to determine if Flame is doing something or waiting on something that it repeatedly times out on.
Brainstorm this list with Claude some more in this direction.
It wasn’t until I pointed the devs at ‘this log entry is the root cause, and why’ that the bug was accepted for fixing.
Now, I do think they have tried to an extent to figure out what is going on with this library situation. But no one has found the smoking gun yet. Until that happens, there won’t be a fix.
lol you’re not wrong, but I really think there might be a way around all this, at least for my needs.
Suppose hook-based tools can also handle the propagation of versioned sequences across workstations, without relying on project server or archive relays. Assume it’s fast, easy, and you can maintain all the project data in PGSQL or whatever you like. Suppose this actually worked, would there still be a reason to stay on 2025 at that point?
Might seem off the wall, but I think it actually might be the path of least resistance. I’d be happy to share prototypes of any of this for testing. No doubt those of you that already manage large-scale collaboration could pick it up and make it way better.
Yes, there are still several functional and performance regressions post 2025.
If this is your workflow for multi-station collaboration, something is very wrong.