Stone/Framestore what even is it how do i get rid of it

Sysadmins Storage
1

Can someone shine some light on what exactly is saved in the framestore/ S+W partition?

as we adopted a unmanged workflow, we dont generate any “important” or unique media “inside” of flame.

We only use the local framestores for 1 thing → playback caching! the actual data is on LucidLink.

Ok, so far so good, all works fine but now I want to take this one step further and have a centralized project server, So thats great, its just a headless flame running in a LXD container or a VM , i get that, easy peasy lemon squeezy, its great i can have all my project data there ,snapshot it, great ill that that to go please.

But then, there is this pesky stone/framestore thing that also suddenly has to become centralised as well, so good bye local cache, but I dont care about the data on there.

And I tried it if I open a project from flameA on flameB and they both point to a non-existent shared location , like flameA cannot access flameBs local framestore - everything turns into checkerboards EVEN THOUGH there is nothing in that stone, flame just really WANTS to have it.

What is it looking for, is that some data that I can somehow store somewhere else? is there a way to use LOCAL stones with a shared project server?

HA I NOW KNOW what its looking for, those pesky .MIO clips that get created on your stone!! so its never just pointing to a file from the flame project to the location on the NAS its always just pointint into the framestore which points to those .mio files which points to location on the nas
the other stuff just seems to be preview files

WHY are they there, why do we need them, can we … get rid of them?

I know I could “Just” get 25Gbit infrastructure just for a stone that I dont really need or want…

I just want to cache to a cache directory thats local to each machine … like resole, i dont want shared cache data :frowning:

Also… what happens if I set my cache to prores422HQ , EXR DWAB (I think there was a way to do that?) and just have my framestore be on the LucidLink partition, is that like EXTREMELY stupid?

Honestly contemplating just pinning the framestore location on each flame and then having one framestore partition inside the project folder?

I dont want any wire , i dont want to have any of that legacy stuff, i just want flame to behave like a tool from 2024 :smiley:

2

The only thing I would add is why not shared cache as well?!! It only makes sense if you’ve got shared storage that is fast enough and want a collaborative workflow then shared cache should also be a viable option.

We actually use shared cache on Resolve and it mostly works well. Not saying there isn’t the occasional hiccup but it is mostly solid.

1 Like
3

Price :smiley:

We have mac studios and running a cache over 10Gbit sounds like not such a great experience, maybe I am overdoing it a bit .

I know fibre exists, nvme storage nas exists, its just another 10K euro down the drain for something i dont really need.

4

If you’re only doing shot work… distributed over lucid, unmanaged, and not doing editorial you don’t need a centralized project server or shared stonefs.

Literally no point. You load a batch, fuck with it, and render which writes out a version and setup. No need to save anything.

2 Likes
5

Yes!

But we also do timeline work and its usually a case of the timelines needing to be messed with by different people and to run client sessions, remote everything is shot based.

I will just try using lucid as a stone, its crazy :shrimp:

6

I can’t remember if LucidLink is supported as a Framestore path, I seem to recall not. But if it is, this should be very easy for you.

On the S+W project server, define the frame store path to your LucidLink location.
Set Shared=True in your S+W config on project server.

On you workstation make sure that LucidLink is mounted at same path as defined on Project Server. Done.

You will still need a live network link to the S+W project server, but it will only server metadata NOT image data.

2 Likes
7

yea thats the idea, i am just testing this with a vpn from home and its slow, like opening a project takes forever

but its fun to see.

it definetely lets me choose lucid as a framestore location on macOS, shared = true and I can see the other flame via S+w over vpn, lets see once the project is loaded :slight_smile:

1 Like
8

I tried it. It worked… but @Slabrie said it ain’t supported so I just push editorial around with a no cache archive. It’s pretty simple.

9

if you are using traditional VPN (OpenVPN) those are usually quite slow and not line rate. Modern VPN like Wireguard or ZeroTier can get close to line rate.

10

yea its wireguard from router to router direct connect , so its pretty nice with 5ms between home and work but flame just crashes on project load and it locked the project on the host and everything wet crazy and slow so… looking into what went wrong haha

Yea we currently use zero archives to push editorial around I just find it difficult to keep track of it

1 Like
11

Lucidlink is not supported as a Volume for your managed media.

12

I mainly try to understand how flame accesses the framestore and uses it so I can judge what kind of solution I do need that will give me what i crave.

if I would do only supported things all day I would not be me.

Ralph Wiggum Danger GIF

1 Like
13

Flame stores cache, render and internal data related to media on the volume. Any project related content is stored in the /opt/Autodesk/project and /opt/Autodesk/clip/ folders.

If you plan to have a non cached workflow and use write file node based workflow like Chris and others then the requirements for the volume are less important but Lucidlink will still not be a good idea to store your volume due to its volatility.

1 Like