Since the release of Flame family 2026.2.1, we have seen more data integrity issues reported for workflows using NFS like remote access, project server and burn. These issue affects Timeline FX persistency and from what we have seen in the lab the file system cache between client and server becomes unsync, causing issue. We have updated the Online help with updated NFS mounting options and some of the cases reported on Logik have shown that these options fix the issue.
if you use NFS in your workflows (macOS and Linux), please have a look at this page and update your mounting options:
This is absolutely insane. These are non standard NFS options that ZERO ZERO other softwares need to operate correctly. Have you analyzed the performance impact of what setting these does in a studio environment with petabytes of data, 10s of millions of files and diverse workloads happening? From my searches, these options have performance a penalty.
I’ve been saying this from the start of the issue, why are you using the filesystem to maintain coherence of metadata when you have a PGSQL database, which its sole purpose and optimization is single source of realtime truth metadata, being used in the absolutely most basic, bare minimum way.
Flame has chosen the most fragile, convoluted path, which we are 1 year onto, and now this crap. We have to intentionally slow down on our NFS performance, consider how all the other functions of the facility are going to be impacted, and hope and pray that this is the one thing that fixes Flame. Nuke doesn’t care. Resolve just works. Maya, works. Every other aspect of our diverse studio, just works. But Flame, no it needs to have special NFS mount options because, instead of using an actual metadata optimized database, for metadata operations, you have to jam it into the Modification time of a file over NFS. And the documentation original started out at 1 second accuracy, and now you are stating sub-second accuracy.
This is a failed approach. And you guys keep doubling down on it for a year. It will never be optimal. It will never be reliable. The only sane approach is database. But Flame stopped at the 2 columns. Why even implement that? Might as well stick with the mono-file BerkleyDB.
Anyway. Flame 2025 it is. This is so lame, as to be basically un-believable this is where we are at.
I hope and pray that gen-AI rules, and puts us out of our misery.
I’m guessing this won’t affect many people, but I was tinkering with the default paths and noticed that the host name tag uses the DisplayName (from the network.cfg) and not the DNS name.
This is something wiretap used to do a few years ago, so when you changed the DisplayName (to a non-DNS name) it was breaking a lot of the wiretap traffic.
Today if anyone is using autofs, using the host name tag in the default paths, AND changing the display names, this would probably break the automount paths.
(edit - the formatter eats the “host name” tags… oops)
Minus the exaggerated language, this is a fair point.
My takeaway from the 2026 launch was that everything would in due time be migrated to PostgresSQL. But that’s a non-trivial undertaking for an app like Flame and spreading this out over several release was a reasonable approach.
It seems to have backfired in this case under certain circumstances. But that’s doesn’t make it a bad roadmap, and they need to keep going.
So stay on 2025 for now. Maybe with the 2028 release they can have all data be sql based and then it will be workable in all scenarios.
Of course would have been good to avoid. But in software projects this big, not every bend in the road is apparent from the get go.
Why this was not found in release testing is however a good question. There seems to be a blind spot somewhere.
