So it seems with Flame 2026 the Clip Library backups freeze Flame on project launch, unable to do anything while it happens. If you have large projects this can take 15-30 minutes and you have to just sit there and wait. Try explaining that to a client paying for a 4K in-theater session with the Director on remote stream. Do NOT use 2026 with large projects and clients until this is fixed. Hell, I don’t even want it that my artists are sitting around waiting 30 minutes for a Clip Library backup to happen.
1 Like
“Why are you on such old, outdated software? Upgrade to the new stuff. It’s great!”
Ok, that’s my cheap shot. Sorry, Alan. That sucks bigtime. I hope Montreal can get you fixed quickly!
7 Likes
ouch that sucks. thanks for the heads up @ALan
That’s the backup of the new ProgresDB, correct?
A lot of ‘simple’ or ‘default’ database back processes do lock the tables during backup to make sure the backup retains integrity. That would stall Flame until it completes. But each database also has ways of backing up the contents without doing so. Seems like some refinement may be required.
Begs the question if the dev team’s automated nightly QC suite includes a ‘large’ project of the kind you have trouble with, or other representative projects? I would certainly have assumed that.
For all the years you’ve filed bugs with them, they should just include one of your projects in their test suite.
In the meantime, can the automatic backups be disabled? I thought you could. Of course then you would have to run those at an opportune time by hand. But at least in the meantime…
Checked the user manual. It’s very scant about the backup/restore of the PostgresDB. The igniter tools is the way Flame manages Postgres. But there’s no documentation related to its backup.
Pg_dump and Pg_restore? Could it be so simple?
Possibly. Disable all auto backup for the time being and run pg_dump during off hours.
Sounds like the next addition to logik project’s cron tab… @philm
It is not the PostgresDB backup that is problematic. It is the Clip Library auto backup tar, which is done as a blocking process upon Flame Project launch. So until that backup finishes, Flame is locked. And that 20 minutes is on one of our smaller projects. We have one project that is almost 3x the Clip Library size. And the big absolute deal killer, would be if the auto backup that happen during a session are also blocking.
So lets look at the data.
Project A Clip Library-
201G / 2,937,506 Files
15-20 minute Clip Library backup Flame freeze
Project B Clip Library-
585G / 36,159,769 files
I haven’t migrated this project to 2026, but give the ~3x data size, and 15x number of files, I wouldn’t be surprised if this take well more than 1 hour to complete the TAR, aka launch Flame.
I wrote this in another forum, and I stand by it.
Why are you guys not testing this stuff with real world scenarios. I’ve provided you guys terabytes of sample footage, batch groups, and Clip Libraries. I really do not believe the Work From Home policy is in the best interest of the software. Studio level functionality has repeatedly not been tested over many beta cycles.
If they want guinea pigs to run beta software in production they need to provide such studios with free licenses to offset the pain and the time it takes to report bugs - imho
How do i explain to my boss that we are paying full price for the benfit of having buggy software that i constantly need to upgrade on all machines… yea I dont so I run beta on my macbook
For nuke we can try new builds and then just open the script in a older version if we need to, we cant do that in flame, once you start a actual production project in beta we are stuck there for quiet a long time.
I appreciate you taking the plunge alan , you are all doing us a crazy service in beign a firewall, you are like adsk QC department or something - I hope they know what they have with you there, I am not ready to piss off my clients doing that…
That statement is off the mark by a mile. A Work From Home policy has absolutely zero connection with the testing strategy or the ability to carry out a testing strategy. Let’s not conflate politics with the aim of making Flame a great tool for all of us here.
These type of tests aren’t carried out manually by some artist, and even if they were, they can be done remotely, just like we work on big projects remotely.
Every major software package these days is tested by an automated test-suite over hundreds or thousands of test cases, usually after a nightly test build cycle. That’s the only way to keep regressions to a minimum. And has been since long before and after Covid.
If there’s any question here - it’s if these automated tests do any stress testing on data set size making sure that (a) the software still runs with big projects, and (b) no process blocks for extended period of times.
There’s a fair question if beta testing by users should have more compensation beyond a badge?
That being said - if you’re in the beta program you can get a license key for your beta system, you do not have to use your login license. I asked that specific question during one of the last cycles. So you can absolutely have at least one if not a few extra seats running as long as it is using the beta software. Of course with the obvious risks, and these seats may have limitations in sharing project elements with other team mates. And you actually have to participate in testing and report problems, this is not a trick for a free license.
And while the dev & qc team should be running stress tests, nothing would have prevented any of us to at least open one of our biggest projects on the beta release and run it for an hour or two and see if it holds up. That includes @ALan. He has found this issue after deploying the release version. But as someone who frequently pushes the limits of Flame in all kinds of directions, he could have opened this project which now broke on a test machine with the beta software and a beta license key and made sure that there wasn’t an issue with the new way media was being handled in 2026. Yes, it would have cost a few hours of time. But it would be less aggravating than having to post ‘Don’t use 2026’ in the forum. And as someone who pushes boundaries, it’s not certain that there are others who would have found that for him (outside of the dev team) until the release. If you have the chance to improve your own journey, you should use it wisely.
The one person amongst us who actually did production projects on 2026 for a good part of the beta cycle was @johnag if memory serves right, and he filed endless bug reports as a result.
So while this is an unfortunate situation, we should the pick the rocks we throw carefully.
Yea thats true that you can get a license for the beta system, that doesn’t mean I can run studio-loads with collaboration on it. The biggest benefit for me is testing our pipeline tools
i can only do actual full in-production testing by running beta in production, for everyone in the studio.
And thats not happening unless I get full-free licenses for everyone , we just do not have the time to spare to deal with beta unless we get it for free, thats just the situation we are in, i dont know how any other studio with multiple seats and ongoing collaboration would be able to really test software without that.
Its simple maths for me, really.
sample maths , 5 Flames:
Costs:
-
Lost time fighting beta issues, call this what 3 Hours lost per Flame /month vs release? so 15hrs/month
-
Time to upgrade to every new build for every machine call this 1 hour per month
-
Time to collect data and put in beta issues, re-creating production issues in clean projects e.t.c varies but id say if I am completely crazy about reporting everything and making sure its not happening in release builds e.t.c maybe 2 hours a week , so 8 Hrs
So total costs here for my case would be 24 hrs, or 3 Days . at a dayrate of 1000Euro that would be 3000 Euro a month lost in time by using beta vs release.
Benefit:
The release version is more stable, would be using release for a few months at most tho, then back on beta to keep it going…
5 flame Licenses are ~ 2400 Euro/Month.
So just saying, i personally think studios and freelancers that really are fully involved in beta development and are really putting in the time to write reports, should get their licenses comped, this would entice a lot more places in actually using beta in production, leading to a much better experience for everyone. Hell, id take like half price licenses too, whatever as long as we can all get something out of it. i have no benefit in improving ADSK development on their software, could spend the time writing my own instead..
There is middle ground here.
You don’t have to run the full studio on it. What I was saying, take one of your project per beta cycle and open it on a beta system, and spend an hour two running through the paces. Maybe redoing a shot or something. The benefit of doing that is so that when the release happens, you know it will work on your type of project, and you don’t find bugs that are a lot harder to fix in the production version than during the beta cycle.
Then the rest of the time, you can use that beta system for one of your artists (or yourself) to do production tasks that don’t require the full collaboration, but that by their nature are more isolated. Many projects have those. And if not, sometimes you have a side project going on that would be a candidate.
-
This really isn’t possible given our infrastructure. Prior to release of 2026 we ran 8 separate 2025.X S+W Project Servers. Each server had 8 defined StoneFS partitions. Each project has its own StoneFS partition. No co-mingling projects in partitions.
-
When there was a beta, I would setup a 9th test S+W Project Server dedicated just to beta. For me to move/copy a full project into the beta S+W is 10s of terabytes of data. Since you can not Wire a Project, only individual Libraries, Reels, and Batch Groups, this becomes a somewhat manual process. Also, remember we are a studio, so every project had multiple Workspaces for multiple artists, so that manually transfer overhead, multiple by N artists. And since, BG Wire is fucked right now too in 2026, so only reliable way is FG. So it occupies my time and a machine for many many hours. Or I could do a file archive, but that again is slow, takes up NAS space and a machine.
-
As Finn stated, testing this takes time. I’ve spent hundreds of hours diagnosing, documenting, interacting with dev. It’s to the point where my business partners don’t even want me to participate in beta anymore as it takes so much of my time. But as we saw during 2026 beta cycle, there were several bugs that I reported which were essentially “did they even launch the software” types. My time is highly valuable, not only to me on a personal human level, but also to the company for which I am not generating revenue dealing with this and the other very fucking stupid untested functionality bugs I’ve reported in the past.
2 Likes
I assume in a facility and setup like yours you’re not flipping the switch and now that 2026 is released you upgrade everyone hoping for the best. But you bring one of your projects over and make sure 2026 works in your setup before upgrading everyone else. The risk otherwise is way too big.
So that requires copying one of your projects over at some point in time. You can do this now or you do it earlier, with some slight adjustments. And yes, it takes time. Doesn’t have to be all your most valuable time. It just has to be someone’s time. This time can be accounted for as part of your own software release management and is part of your risk management budget.
I don’t know your workflow or setup in detail. So I can only comment in general terms. But I’ve been around software and deployments for a long time, not just making stuff up here.
Yesterday we were at a big NY facility and doing a workflow demo. They are still a few releases behind (not Flame). Roll-out of primary apps at larger places is painfully slow. But also for a reason.
Regarding bugs of ‘have they even opened the app’ - that’s a separate topic, and is a fair discussion.
This is not a fix, but a workaround. There is an environment variable that will completely disable all Clip Lib backups. You need to know what you are doing here, as in a catastrophe, there will be no recourse. For us, our NAS does 15 minute snapshots anyway, and the VM that is running that actual DB has its own backup mechanisms.
1 Like
Good to know. And yes, at this point workarounds are useful until the devs can get a handle on the situation.
Can you share the env variable?
I’d rather people get it from ADSK. Many of the env variables I use have been given privately and discouraged for public use.
But let’s say someone runs a ‘strings’ on the flame binary and saw a DL variable relevant to the TAR archiving of clip libraries, that might just work.
4 Likes
IIRC the env variable is: DL_ARCH_SKIP_TAR=1
1 Like