Hi!
We have two Flame suits at the office. Once in a while we would like to send a sequence or batch group to each other. One trick is to through the MediaHub go to the projects tab and enter the other machine through there.
Yesterday we did this and imported a batch group from machine1 to machine2, all good. But when the user of machine1 opened the project and entered that batch group the node structure were all gone. The batch group instead contained all of the assets of that comp (EXR, renders, source files), none of the nodes used to make the comp …
Is this something you have experienced? Its pretty scary and damaging.
Please let me know if you know why this happens.
Hello. I’m not sure if this is related to an old bug that would happen from time to time, with the schematics disappearing but the source clips remaining. It’s a terrible thing to happen. I don’t think it’s related to sharing the batches though, as I experienced it a lot with just one box.
I would save as/iterate prodigiously.
Have you tried going back to an earlier iteration or ascii setup?
I have found that archiving from one machine and unarchiving from the other is a much more dependable method, although slightly more time consuming. In your case, if you saved the batch as a setup on machine 1, I would try reloading that.
yet again guys… Centralized S+W server for the win here. To think that it is an acceptable methodology to have to archive/restore to share things between 2 Flames on the same network is total insanity and reminds me of pre-Wire days which is like circa 1997.
Not everyone has someone like you on staff to set-up and maintain such a system. Particularly in a two-seat shop which may not even have one full-time or staff artist, much less a full time, experienced system engineer with a knowledge of both hardware, software, and the unique intricacies of flame. You may scoff and say it’s not that expensive or difficult, but in reality, it is, just not to you. What’s more, convincing those who are in charge that it is a worthwhile investment is incrementally more difficult when you’re not the one in charge. Money people don’t like to make big investments in complicated technology because their artists would like to do something “once in a while.” Most of us have to play the hand we’re dealt. I think it’s better to help someone play their hand than to tell them they’re in the wrong game.
It is also a condemnation of ADSK that people have such problems and resort to nearly 30 year old workflow because very normal models of computing data sharing either don’t work or are not easily accessible.
I definitely saw this in Flame a few years ago. We actually found that some archives were not reliable as when we opened them, we’d find exactly what you described; clips but no nodes. Since then, whenever we archive a project, we make sure we check the archive by not only restoring media but also by restoring batch setups. We do all this before we delete the project. You can do things on your end to help safeguard against this too… you can save batches manually as well as create a .tar file of the setups themselves.
This, again, is not a solution to your problem but an alternative that we use with two Flames.
We have a Linux P620 with internal SSDs as the framestore running as the main Flame. We also have a MacStudio connecting to the Linux box over 10G. Both machines run smoothly without a hitch even working with 4K, 12bit images. Timelines are 1080p @10bit and the two of them can play concurrently.
We use different workspaces when working on the same project, using Shared Libraries just to transfer stuff with BFX.
The perfect workflow as for now is to save batch groups locally and/or archiving setup and then check them afterwards to see if all data is there. Or use shared libraries.
Sure, that’s a logic step to make cause its data and stuff can happen.
In our case it just came out of the blue cause we just wanted to copy one batch group from one guy to another, erasing the project/comp wasn´t even considered.
We had a backup library, unfortunately it was a earlier iteration, but that what we got…