I’m looking for ways to improve and expand our data handling across teh two edit suites we have, and wanted to check my ideas are valid with those much more technically aware than I.
Currently each edit suite is running Flame on MacPro 2020 Towers. Each has several external raids attached via TB2 cables. Framestore is on the same raid as the rushes, graphics etc. We don’t use proxies, or cacheing (yet). Everything gets backed up to a large synology nas (and a remote mirror of the nas)
As rushes seem to be getting larger and more complicated to handle, we’re running out of space and the Flame is struggling to keep up with data throughput, so i want to improve things.
My thoughts are to install in each mac a HighPoint SSD7140 8-Channel M.2 NVMe RAID Controller along with 8tb NVME, then use this internal raid as the framestore. Load any rushes and graphics onto this raid, then work from this at higher speeds than across Thunderbolt.
When project is complete export the deliveries back to the local raid, delete any unused rushes from the local raid and archive the project into the relevant project folder on the local drive.
When importing the rushes etc to the Internal NVME, Is it more efficient to have a single NAS acting as the local storage or stick with our current individual local attached drives?
Do you share much data between suites? Are you working on the same project at the same time on both systems?
NAS would make more sense if you are sharing data. If they are completely separate though, you’d get better performance from direct attached.
Instead of copying files into the NVME, I’d just use Flame’s cache functionality. Saves a manual copy and it is easy to delete the cache if you suddenly needed to free up space on your internal NVMe so you could go back to looking at your original source media.
2 Likes
thanks Adam,
no - we don’t share data between the suites. Its individual projects on each Flame.
As for the cache bit - is that the Proxy settings you are referring to? I don’t remember ever seeing anything called cache!
When you import clips there is a setting in the bottom part of the window that says “Cache Source Media” or something like that (I’m not in front of a system right now). If that is enabled it will cache the media in the background.
Also, if you right click any clips on the Media Panel, you can select Media>Cache Source Medi and it will cache it for you.
I’ve explained the difference between proxy and cache on your other thread.
1 Like
I’d definitely just keep the drives locally attached in your case. There is no benefit of setting up a NAS in your situation apart from if you wanted to easily share the same storage to multiple systems.
The workflow Is suggest would be to conform from your direct attached Thunderbolt drives, once conformed I would then consolidate your media to whatever amount of handles you want, then cache the media in your confirmed timeline.
2 Likes
in that scenario, after conforming the edit and caching it. Once final approval has been given, could you re-export the contents of the edit from Flame to a separate folder on the raid, thus allowing you to erase the original rushes without losing the conformed takes?
Thats the kind of workflow i’m looking to instigate - our projects are getting massive purely because the production company is shooting bigger resolutions for no apparent reason other than the camera can do it! I want to find a reliable way to prune out the rubbish once i finish a job.
Like a Media manage/consolidation?
You could export new media from Flame by publishing it which would write out new media.
Two other options would be using YoYotta to do a media pull based on an EDL or AAF. It can selectively copy and trim media from one location to another. Or you could conform in Resolve and use the Media Management tools in there.
Unfortunately, Flame is lacking some tools in this area.
2 Likes
Yes, that sort of thing. Just looking at the various ways available to help eradicate the nuisance of storing the unwanted detritus from a shoot…why waste storage space on bad takes and such like.