OpenClip Housekeeping

As we iterate through some batches using the unmanaged storage / open clip workflow - is there a tidy way of purging old and no longer needed version (or faulty versions)?

Both in terms of the version list and the old files…

I know I can go into the folder and find the exr files and delete them. A bit painful in a folder with multiple versions unless you have a folder per version.

I know I can go theoretically edit the XML and then make sure Flame re-reads.

Both are non-optimal. Is there a UI way of purging and old version? If not, should there be one?

1 Like

I’ve wondered this too, especially before archiving.

This is why we use a hybrid workflow. We use Render nodes when doing iterative comping, so fully managed by Flame. Then when we like a comp, we attach the clip to the Write node and publish it out. Otherwise, we’d have 100 shitty versions on disk we don’t like taking space on the NAS.


I’ve been working on a script to prune render versions from 3D but it could work for comps as well. It won’t fix the openClips themselves though…that’s a whole different beast.

You’ll want to modify line 31 to work for your structure. Right now it’s looking for:

So if you’re structure is

then change the “renders” to “comps” on that line.

python -t # /path/to/start/scranning

The -t number is the threshold, so say you want to keep 10 versions, then enter 10. Everything beyond that will be marked to be deleted.

You’ll be asked if you want to delete everything and be presented with a list. You can also use the -d or –dry switch to do a dry run to test and see what would happen.

Let me know if you need any help setting it up for your pipeline.


That’s great. I should be able to adapt that quiet easily.

Longterm would be nice if there was something in the UI. Will have to fill out a feature request.


After playing with this, a slightly different approach - while doing iterative comping, simply overwrite the previous version. I’m using ‘custom versioning’, so I get to pick my numbers. It auto-increments after each render. But if you just take it back to the previous version as you render, it over-writes the previous version and the timeline and everything automatically updates. Don’t have to do anything.

So only allow the version number to increment for the publish. That avoid a hybrid setup.


For anyone who wants to test it: del_openclip_versions

This script is a variations of @john-geehreng’s recent ‘Add Version To Openclip’ script which is already on the portal.

This script deletes OpenClip versions from the MediaHub. Go to a clip, right click for menu and find the script at the bottom of the menu.

It retrieves the versions from the OpenClip. You have two choices: You can select a single version to delete from the list. Or you can change the top button to ‘All Other Versions’.

For obvious reasons you can never delete the current version. And thus for the script to work, there have to be a minimum of two versions, or it shows an error message. A single version deletes the selected one, and ‘All Other’ deletes all versions except for the current one.

So if you have 14 versions accumulated, and are ready to ship, ‘All Other’ will clear out the clutter.

The script deletes the .exr files and updates the .xml to reflect the change. So this is a destructive script, no undo.

One thing I’ll have to look into another day, is the ability to select multiple OpenClips in the list and apply the script to all at once. Might get complicated with a single selected, but could be useful in clearing out older versions in bulk.

Happy to hear comments and ways to improve…

One we get a bit more mileage, I’ll find a way to add it to the portal.


Pop Tv Bro GIF by Nightcap

This is the approach we’ve been using at my shop for a while. It works really well, but I find it a bit of a pain to remember to reset the version number sometimes.

But then your OpenClip version has no relevance to your Batch Group iteration and when the client says I liked v04 of the comp and your are on Batch v275 what do you do?

There are two ways of working - you can select versioning to reflect the batch iteration in the render settings. Which is what you describe.

Or you can use custom versioning, in which case you can freely assign numbers. And yes, they may not match the iteration. That comes down to how your pipeline works.

Custom numbering can be useful in smaller pipelines where you’re not shot based but simply use batch with OpenClip on the timeline instead of BFX.

In my last project the batch itself never changed, the only thing that versioned were CG and GFX plates. I could have versioned the batch iteration, but it wouldn’t have made much difference.

The ingredients are there, what you do with them is another debate. In bigger project more strict versioning is definitely required.