Archive Crashing Flame 2024.2 and 2024.2.1 and Support is Unable to Figure It out as well

Well,

I have a large project 4T with a lot of Batch Groups, Libraries, and Reels.

Everything was cached on a HiPointe SSD Raid from a Synology NFS Share and rendered and consolidated to 48 handles.

When we try to archive the project, we crash Flame. No true error messages in the logs or terminal. I was even able to get Beau @ ADSK involved.

So, we have tried to wire to another machine, pull things one at a time, new user, reinsatalled flame, etc.

No errors in the sw database at all.

But can’t archive only metadata, with caches, or anything. I can archive setups alone no problem.

I can archive some individual items, but the batch groups and BFX all crash the archive.

Beau has narrowed it down to the schematic in batch, as he can archive the batch media no problem, just not the batch with the schematic.

So, I am at a point that I feel like I may be screwed and this is a very important job to be able to archive.

Not sure if anyone has any ideas, but if I find out something, I will share.

I think Beau is feeling we may have to archive the media and then save the batches and BFXs out in file format. The dev team is scratching their heads as well.

I have not tried to remove my new BFXs I create to render the Neat Video renders instead of prerendering them that I learned from a recent Logik Live. Wondering if Neat Video and the BFX is is causing the issue. Or would compasses have too long of names cause that?

We did find some error regarding photoshop mio as well. But there are not Photoshop files in the Batch Groups. So, not sure about that.

Well, I am extremely tired, so will try to put more info in here tomorrow.

Thanks for any thought one might have.

I don’t have as much mileage on Flame as many others here. But with my software hat on, getting out of a corner like this - divide and conquer.

If you cannot archive the whole batch as is, can you copy & paste section of the batch group into a separate new batch group and see if that backs up?

If you have to archive it as three sections instead of one, an archive is an archive, and if needed you could stitch it together with some renders between them, or append into a new big one.

If you broke it into smaller segments, it might either also get under the critical size threshold and just work or you would find out which section still keeps crashing, and then sub divide that until you find the node that’s the culprit.

If you know what the problematic batch group is, select all the nodes in the last iteration and copy and paste into a new batch group. And archive that. If that works huzzah. If it doesn’t, then duplicate that, and start deleting half of it at a time to find the culprit.

Wait is it one batch group or many?

Check for illegal characters in batch names / compasses / kill all long names.

I’ll give that a go.

Unfortunately, I have 31 of these to deal with…

Hopefully, it will be the same fix for all of them. We shall see.

Marc Wellington

CMG

www.cmgindy.com

Facebook

@CMGIndy

317-536-0660

Kill the live Neats too.

Ok.

So, I created a new batch group. Copy and pasted the WHOLE schematic from a troubled batch group. I was able to successfully archive the new test batch group with and without caches and including Neat. The only visible difference is there were no batch renders.

I was able to also load the saved iteration of that batch group and it works as well with and without media.

I copied all the renders from the non-archivable batch group to the loaded batch iteration, and it archived as well.

I have no idea what is bad in those batch groups that kills Flame instantly when trying to archive.

So, looks like the potential plan:

Spoke too soon.

After a few batch groups, I am back to crashing again.

Diving deeper and trying to figure it out.

Will copy and start deleting things until I get further into it.

Man this is little rough.

Ok. In the process of doing what I have listed earlier in order to get the batch groups to Archive, but I have found an additional issue causing a Photoshop mio error. There was a PSD file that for some reason, Flame decided to put in colored noise in the thumbnail and that crashed Flame every time I tried to see what the file was or open it. I thus, deleted all instances of that file in the project that showed digital color noise as a thumbnail and all good on the front. There was one instance of that file that was A-OK. Head scratcher.

Worked through the project, but all Batch groups have been reloaded and now archive.

Long story shorter…

I was only able to archive as follows: After the above, I wired all the batch groups to a new project with the same name on our second flame. Then, reels, libraries, and share libraries. Then archived the project from the new Flame. To be able to have all the iterations and such from the batch groups from the original project that wouldn’t;t archive, I then went to the original flame and opened the new archive we just created and then archived the set-ups only. Now I have an archive with everything, just have to restore the project first, then restore the set-ups.

However, we did find an error. I did restore this whole thing onto another flame to test it out. Everything was good except, we had a Batch Group that was missing. I did have the set-up saved. I loaded the batch group from the saved set-up, however, all footage, except the root, was all wrong. I had to reload the footage and line it up manually. Not sure why. But overall, I was able to get a version of the working project archived, finally.

Beau and I worked on this for days to try and figure out what was causing the error and crashing to no avail. You can archive portions, but not the whole. Just glad I was able to get it archived, finally.

1 Like