Current project I’m working on was, lets say “magically”, switched to work off of my iMac Pro’s internal drive, not my external- so mid project it has dropped from about 800GB free space down to 250- is there a safe way to migrate this project (or create a new one), and nuke all these old files?
Could I:
Create a new project set to the external drive
drag desktop folders & batches over
delete old project
Would that be a route, or does that do nothing other than move things around?
Do I archive, delete the entire everything, then re-install and unarchive?
If I’m reading your question correctly, then yes, you could absolutely make a new project that references your preferred framestore and then just drag your stuff over (I’d turn off BG wire so you can verify immediately that it’s actually moving things), and then, once you’re comfortable that everything is working properly, delete the old project.
I’ve done this, as I experimented with different storage setups after purchasing my home machine, and it works.
Archiving and then restoring is easier and probably safer, and has the advantage of recreating your original project structure without you having to do anything, but I don’t remember off hand how it deals with multiple framestores, so there may be some trial and error. If you’re in a hurry, however, your first idea may be the best.
I also found out that time machine (while designated to a drive that wasn’t even connected to my computer) was somehow writing whatever the F I was doing to my local drive- grateful a friend of mine suggested Daisy Disk- i purged the time machine shit and it free’d up NO JOKE 500GB of space… insanity i tell you.
Yeah, I disabled time machine on my “work” mac and rely on a bunch of individual Chronosync jobs to back up my project archives and clone my system drive. I’ll trade the hands-off simplicity of time machine for a more granular, reliable, and manageable solution any day.
Also, and I’m not suggesting you don’t already know this, but there’s a reason people on here are always alluding to their massive collections of outboard drive arrays, it helps to have places to put large things like archives when problems arise. It’s also fun to buy drive arrays, not gonna lie.
Plus it makes things like a dead framestore more of an inconvenience than a life-ruining event. The folks using their system disks as flame storage possess, shall we say, an optimism that I will never experience.
this is really strange, its showing an FBX inside of an action that i have as whats taking up space- and that exists only on an external drive with everything else:
Ooh, yeah, unless specifically configured otherwise, by default opt/autodesk will store all project metadata (this used to be fairly lightweight, but since clip history and its successors bfx and timeline fx, it has gotten quite… girthy). Footage and renders go to the framestore, setups and database stuff stay on your main OS disk.
So, your options are limited. I would make a directory on your desired drive and create ANOTHER project, using the “setup directory” pulldown in the project creation dialog to send the project metadata to your preferred drive. This should reduce the pressure on your main disk, but I should also mention that I sprung for a 2tb system disk on my Mac for precisely this reason. So, that’s your second option: upgrade your root drive. Seems like 250gb is barely big enough for the OS these days.
I have a 1TB- but it was just going down and down- didn’t realize it was so drastic until i noticed it was at 250, then dropped down below 50GB without actually doing anything.
That will do it! I was worried you might’ve stumbled across a weird thing I had where crash reports filled my system disk. You’re probably just experiencing the fun of “every iteration save dupes your geo and fbx” it’s also possible that those saves are duplicated again as your desktop autosaves are backed up by flame.
That will fill a disk mighty quickly if you’re not careful.
So, having roughly 770GB free on my local drive (basically blocking this out for my geo/fbx storage), as long as I don’t iterate (and just version up my rendered files manually-or delete my previous iteration), I should at least stay in a safe range.
BUT, if I keep iterating I should plan on space depleting quickly for each iteration. correct?
Right, and if I understand the current architecture (and I may not!) more iterations containing geo and fbx, plus multiple flame-spawned clip lib and desktop backup sets that each get bigger as you add iterations, means your available space will vanish that much more quickly.
Now, I use fbx a LOT for 3D tracking (with zero or very minimal geo) and haven’t experienced the issue you’re describing, so it may be down to more complex geo or there may be something else going on. This is probably where a responsible person would tell you to contact support if you’re in a bind or seeing something truly inexplicable. But it’s Sunday on the east coast now and getting a human from autodesk to help you in the next 24 hours is going to be a stretch.
I don’t know what size of geometry you’re dealing with, but if you’ve got the space (and the time) setting your project directory to somewhere spacious might be a good move.
What’s weird is my project directory is set to somewhere spacious- yet it keeps writing to my internal drive, not the primary storage drive (an external drive). So. Strange.
Well iterations and all project metadata are going to be stored inside opt/autodesk regardless of your framestore path for the project unless you specify otherwise. That will include geo that you import.
