Archive - with no pics is 2TB

[johnt]

@Jonhollis

…Hi - thanks for the info. I would love to just be able to save the project though. the setups doesn’t really cut it. so the whole project but all the media missing. I think this is part of the wider thing for me where I would like the project to be stored on my drive. so I can walk into any flame suite hook up my thunderblade drive and carry on working.

We got it working like this so we could carry a drive exactly as you say.

I’m sure this has been said but just to reiterate: all media is soft linked. Archive is set like photo with all cache off:

[Jonhollis]

Exactly what im doing and its 2TB!

[johnt]

Have you tried flushing source media cache?

[andy_dill]

the hard part about this is there’s not an easy way to search for “sourceless” clips (batch renders, motion vectors, other flame-generated media) and segments in flame, so finding whatever element is is making your setups go from the usual 7.91 megs to 2TB can be hard.

Here’s my FR for that

[cnoellert]

@Slabrie

… in Batch that allows re-importing the result of Write File node. That means that in many workflow, it would be more beneficial to use Write File instead of Render node. And since the result of the Write file is seen as a source, which could be cache or not, then metadata only archive will be easier.And since the Write File can generate multi-version Open Clips, you very easy versioning if needed.

This is the way… although with the import write node Python script from the portal it was possible before.

[Slabrie]

True but as we know, many artists are not allowed to install Python scripts or as freelancers do not have administration privileges on the system they work with.

Have fun with 2023.2 Update!

[johnt]

I added my vote to this. It’s an interesting request. I think the solution might be to move more toward @Slabrie ’s suggested nuke type workflow.

It’s worth a big discussion, think and test.

[andy_dill]

Yeah, un-cached is fantastic. Moving setups between machines is instant, for example, because there’s no media to move across.

And for playback you can still cache timeline renders and get the stone speed, then leave “archive renders” off and keep the archives tiny. A win-win.

I think this FR will help bridge the gap for those who still work all or mostly cached by allowing them to isolate that media, think about everything more constructively, etc etc

[Jeff]

Hey there Jon! I have some insight into this subject and I’d love to try to help.

There are a few key pieces of information that you should know about Flame in general, and then there are a few wonderful troubleshooting techniques that I’ve learned along the way that help you pinpoint exactly where the problem is.

A few people have hinted at this above but any renders generated by Flame will always be included in your Flame archives regardless of any checkboxes in the archive settings. The only time a Batch Render or otherwise Flame-Generated source is not included in the archive is when it is manually unlinked via Media → Unlink. As Stephane mentioned, the best way around that is to, from the beginning, use write nodes instead of render nodes. In my experience, that’s most likely the culprit. That and any layer in a timeline that has been hard committed. That is also essentially turning a render that would otherwise only exist as a cache file on the stone into a clip that would from that point on take up space in an archive. The only thing that makes this scenario complicated is that it’s one thing to remove the renders in the Batch Renders location, but if those renders are used in the timeline, they will still take up space.

I ran into this particular issue recently and I found myself re-rendering the batch with write nodes, using source segment connections to connect the clips in all of the sequences that had that batch render, and then replacing the media with the render that was written out to the SAN. In all it was a quick process but depending on the complexity of the job, this could be a big deal.

To narrow down the specifics, what I like to do is go into the archive in question, and instead of archiving the whole project, just drag in individual elements, one at a time. Maybe a batch setup, maybe a library, and see how much space it says it’s going to take up. That is your best indicator of what’s the problem. The only issue there is sometimes you may have iterations in a batch setup and depending on if you have those set to hidden or not you may not be able to see everything you need to see. This has been my surefire way of knowing what is taking up the space. The next step is figuring out the why.

[Jonhollis]

thanks but I know all of that - I guess what im saying in my round about way is please fix it autodesk. no renders should mean no renders.

[Jonhollis]

@Jonhollis

hi all. ive got an archive of a big project. but have everything turned off as I only want the setups. says its going to be 2TB - - - what the hell. why?

So ive just gone through the project and gone through 500 batch setups and deleted all the iterations and renders. and now the archive down to 90GB. which is fine. took me an hour and a half to do this though. which is mad. if im on something like resolve for example I just save the project - go on a new machine and then open it and hit relink all clips and bingo im working - or even better use the cloud projects - its even easier!. archiving without clips should just work and a smart relink should just exist.

[GPM]

Ouch. Yeah I had a chat with the devs some years ago, emphasizing how useful a simple no-media archive function would be. Like a single button that disallows adding any media to the archive. Clips will show up black in Batch of course when loading.
But I don’t think I ever made it into an official feature request. My bad…