Looking into how we can deploy and use 2026 - i wonder where I should park my media cache and how I can recover from a loss of this data if it would happen
I am saving my Project home and Setups Directory on my project server as before, that thing is snapshotted and backed up constantly 3-2-1 and everything as its running on Proxmox in a VM, so far so good this data is “very safe”
We are not generating any Media in Flame, so our media cache really is “Volatile” it just needs to be fast, if we loose all the data on it , it wouldnt matter. technically . its just timeline renders bascially.
So then I went ahead and Deleted a media cache folder for a test project, and I am stunned that all my soft-imported media ist checker-boarding , i guess due to the missing .mio files from the cache.
Should these .mio files if they are so important to the integrity of the project be part of the project home and not i a location called “media cache” a cache by definition is volatile isnt it?
How would I recover from such a catastrophic loss? I seem to be somehow able to get some media to pop back in if I go into format options and change the scale option back and forth, but in general?
I would rather not have this “media cache” location constantly backed up 3-2-1 as well especially as its very much re-render after re-render so snapshots would just completely explode.
All I would need is flame to re-generate the mio files?
This may have historical reasons around S+W architecture, or who knows.
But the bottom line is, it’s not a cache, but application owned storage you’re not supposed to mess with. That doesn’t seem to have changed with 2026, the only thing now is that you can pick the place it’s stored as part of your standard storage setup.
Looking in my ‘media cache’ folder, it’s intermingling in the same disk folder .exr sequences from batch renders and .mio files which are metadata for files in the project, including non-managed media.
Long way of saying, you need to include the ‘media cache’ in your backup and treat it like the rest of the project.
If that is the case, then this would indeed have failed the intent of the entire endeavor of separating the truly volatile timeline temp renders from the ‘must keep’ files in order to keep your backups smaller. Which if true would be a major project management / software architecture miss by the team.
My guess is that the way of managing these media folder has deep tentacles into the entire code, and it would be hard to change they way these files are stored on disk (S+W or user folder).
That said, it may be more manageable to have two separate folders, which retain the logic by which these folders are managed (the filenames which are IDs into a database table, etc.).
So you would have a ‘media cache’ folder which would hold the .mov and .exr files. And then you would have a ‘media data’ folder (or pick your favorite acronym). This would have the .mio files and other non-volatile data.
Then you could keep your ‘media cache’ folder on something that is not backed up (and high speed), and you could keep your ‘media data’ folder together with the project folder that is fully backed up (and can be on slower disks, as it’s just metadata).
That may be be a more manageable approach from a dev effort, yet embody the goal of separating truly volatile and critical data, while maintaining the existing tech infrastructure for managing these file stores.
“media data” “mio” if this important to the projects integrity should just be in the postgresDB would be my 2c no need to have that extra right? no?
I guess it all ties down to that notion of people working and creating managed media which ughhh , why would you do that to yourself I wonder…. its so … old. eww.
I am also pretty sure there is a feature request for archiving without media (no matter if there is managed media in the project) which would also sort of solve that issue for me.. but thats been a looooong standign request iirc.
→ I can dump the whole project as a archive nightly and automated, which is neat and it carries everything I need in a small easy to backup file, its perfect. apart from that if anyone creates managed media by accident i am dealing with potentially teradbytes of motionvectorcaches … sigh.
The migration to ProgressDB is not simple nor fast, and is coming in multiple steps, as Stephane has been clear about and is more than reasonable from a dev effort point of view.
Eventually they will end up where Resolve is now (in terms of the DB being the central storage of all project and meta data).
Which btw - it’s been a while since I looked at the DB schema of Resolve in their ProgressDB, but what a f* mess Smooshing together DaVinci, Fairlight, and Fusion has not created a clean architecture there.
This is all non-trivial, and a tech debt tax that lacks funding like so many things in life these days.
Maybe we should let Claude just rewrite it…. (tongue in cheek). Can you imagine what a cluster that would be. ‘You are right, I should not have deleted all the data in the ProgressDB’ claims the apologetic but confident AI bot.
i will for now just have to deal with like 2hour based snapshot syncs to another server that rotate only the last 6 or so are kept and then .. thats that i guess.
Whatever it is, but i am not having any fun here, cant recover a 2026.1 archive due to random errors and issues, and flame crashes, my project is so slow on the project server that its unueable,
I have a full project server so its kinda like a stand alone flame just sharing projects out . its just smaller, has no GUI etc and runs without any nvidia cards (for example in a virtual machine)
your choice, i am abandoning it personally for now make your own tests.
Id argue between flame and flare there is no need to share projects, you cant access the project at the same time either, just use openclips and open the comps on flare while
keeping the timeline in flame or flame assists, its a solid workflow.
I have had numerous other issues with 2026.1 like
ocio config just corrupting itself / lost all my view transforms in the middle
of a client session among other weird things so ill wait until its matured
In all honestly what is a workspace even, ifs a sub project in a project.
You cant bin/reel lock and work collaboratively in flam on one project workspaces might as well just be a compeltely different project it you ask me.
Doesnt make sense to me to use workspaces if we can just render shots with writefiles nodes and openclips and have our batch setups live on some nas instead of barried in workspace 3 … but thats just me i never got warm to the idea of workspaces, to me shared libraries are nonsense.
Even on vanilla flame you can open a local project or jump into someone else’s remote project and use a different workspace. All day long. (Not long happy days…)
Yea you might want to have a look at that again, so openclips are inherent to unmanaged workflows in flame but your requirements are porbably very different to ours.
but I dont have access to anything in the main workspace so what am I gaining here?
I tried this workflow and it was just utter confusion of whats where and why, someone wired a timeline over did a change then put it into shared libraries and yadda yadda .
write it to disk, like nuke , have it on disk, back it up, be happy. dont even have to have the same exact flame version, can be on the other side of the planet, doesnt matter .
as the mio files are part of the archive.
Smooshing together DaVinci, Fairlight, and Fusion has not created a clean architecture there.