View Full Version : Can I recover a project in FCX???


Joe Holt
July 2nd, 2013, 07:54 AM
I won't go into all of the gory details but after about 10 hours of work on a project, I accidentally deleted a spacer at the head of the timeline. Everything on the timeline went away and I was left staring at a blank "new" timeline. I hit "Command Z" and got the nice little blip tone. I check the edit drop down menu and of course "Undo Delete" is not available! I spend the next couple hours trying to locate a backup and install it without any luck. I found a project backup in the FinalCut Projects Folder but for the life of me, I cannot figure out how to get FCX to revert to it.

I am new to FCX and was never a big user of older versions (I know enough to stumble my way around FC) Is there a way to recover my project or am I totally screwed?

Not being able to undo was a real shocker. After coming to terms with the fact that I will have to start over again, I shut down FCX and relaunched it and behold, Undo is available again. All I can think of is the system memory was full and FCX suspended the Undo function. The weird thing is there was no warning at all.

Any insight would be most appreciated. I was just starting to like FCX but not having a way to control how and where I can backup my projects is ridiculous.

Nate Haustein
July 2nd, 2013, 08:14 AM
Close FCPX, then rename the file in the backup folder "CurrentVersion.fcppro" and drag it into the project folder replacing the corrupted file of the same name. Open up FCPX and see if it works.

Joe Holt
July 2nd, 2013, 10:26 PM
Thanks Nate. It did work sort of. I was able to replace the current project version with the backup version. Unfortunately, the backup version must have been updated since the catastrophe occurred. The real question is why was undo disabled? Doesn't FCX have unlimited Undo's? I would have given a mint for just one undo last night. It is also unfortunate that my time machine drive was not connected because it was full. Wouldn't you know it, I had the replacement drive sitting in a box waiting for me to swap them out. Lesson learned. I probably could have gone back through time machine and grabbed an older backup if the drive had been connected.

Bill Davis
July 5th, 2013, 02:37 PM
Joe,

In case you come back and see this...

FCP-X is NOT designed like prior editing software in that it does not build a huge monolithic "project" file that can easiily become corrupt.

Everything X does is simple metadata kept in text listings. This is why it's pretty difficult to actually "crash" the program and lose data. It's constantly writing metadata updates in real time - as you do stuff.

That said, there's no computer program in existance that can't go screwy. So knowing how to manage the metadata container files (CurrentVersion.fcpevent) and knowing about where and how X stores the saved state of that metadata can be very useful.

But if you're like me and have been thinking for decades that there's a big container of files that needs to be managed and backed up and archived - is not really true any more.

Yes, you need to back up your Master audio and video files. Yes, you need to have the proper FCP Project and Event files present for X to load them when it opens. Yes, if you bring in a lot of assets like stills or sound effects, or custom titles - you need to store them in places where X can find them when it launches. But the work of building actual FCP-X "edits" is done in extremely small text files that seldom get screwed up (just as, for example, MS word files seldom get screwed up.)

As you get your new X workflow organized over time (whee and how to store assets and load and/or unload projects and events) you'll start to see that it's a more "modular" system than the one we were all used to in FCP-Legacy.

So "backing up" projects is a very different beast particularly once you learn that there's really no big need to "read in" large video or audio files into your projects to work smoothly and efficiently.

It takes a while to understand all this, but I find it to be a much more flexible and agile system than the old one.

FWIW.

Joe Holt
July 5th, 2013, 02:59 PM
Bill,

Thanks for the insight into FCX project file architecture. Can you advise me as to what I could have done differently to recover my work? Undo was completely disabled (Obviously a freak out of the program) Without Undo, how can I recover from a mistep? Am I right in guessing that in the future, I could enter time machine and go back to a previous version of the project file or the backup? Losing that work was pretty devastating and is something I would like to avoid in the future. I still don't understand what happened and hope it doesn't happen again. Joe

Bill Davis
July 6th, 2013, 02:12 PM
Pragmatically, this is kinda tied to the level of system stability you've achieved.

FCP-X is very modern software. As such, it works best on modern hardware and it also wants pretty robust resources in terms of CPU, GPU and storage systems. Many problems that I've been reading about over the years - particularly relative to the program hanging, crashing, or simply being unable to properly calculate and get it's job done - seem to be at least somewhat linked to "resource starvation." - someone will say the software "won't" do something - and upon investigation we find out they're trying to process 15 streams of interframe AVC-HD without transcoding to ProRes. (not saying that's what you're doing at all, just that they haven't come to understand that all video isn't created equal and that in a "high precision math" calculation engine like the one in FCP-X - it will definitely TRY To do all the number crunching required to decode, calculte the missing inter frames, apply user metadata, and re-encode and work with whatever you tell it to - even if that results in an insane math load under the hood.

IME, X will "crash" most often when it's hardware isn't up to the tasks you're asking it to do. So knowledge of what operations tax the system is useful. Part of that depends on how you set it up, since it may be doing substantial calculations in the background while you continue to edit. A modern fast robust computer may face a flood of calculation with ease, while an older one might get stressed to the point of slowing down tremendously or even hanging up.

While those calculations are going on "under the hood" the actual "interface" of X does virtually everything by simple text references stored as metadata. These are typically very, very small files in the great scheme of things.

The "undo" queue is really just the software looking at the metadata it's already stored and stepping back action by action. It's not as if it's keeping some volatile separate "undo" record of what your edits or colors or timeline settings used to be in big separate files.

This is partially why "backup" is a different beast in X. You just need the state of the metadata before something went wrong. These files are created and maintained by X as part of the necessary FCP-X Event and Project structures. In your storage drives Movies folder: inside both Final Cut Events and the Final Cut Pro Projects folders: you'll find Backups and Old Versions which both store earlier metadata states. These are VERY small files since they're just text.

If your actual event gets corrupted ( a rare thing IME) you can easily go rename and move into storage your present CurrentVersion.fcpevent or CurrentVersion.fcpproject files and replace one or both with versions of the stored backups. Be very careful to copy and save these files as you manipulate them in case you discover later that you need go back and access their data. Again, they're just small text files, so there's no reason to over-write the originals, just re-name and more them into temp safe storage.

On re-launch, that whichever prior backups you've named as the CurrentVersions - will be what X believes to be the current state of the project and launch.

So a "recovery" is NOT the same in X as it was in a traditional finder based system. And what typically goes wrong isn't the same either. Sure things can go wrong when anything is written to a hard drive. But modern programmers undersand that and can write checksum routines to make sure that what needs to be written is written accurately.

This metadata foundation and constant updating of the database is why X is much more "crash resistant" and hardly EVER loses even the most recent few keystrokes you've done.

BTW, now that you know where these metadata files live should not, IMO be confused with thinking it's OK to play around with them. X wants specific files in specific places in order to keep it's database intact and useful. This is why moving stuff around via drag and drop in the finder is very much frowned upon for FCP-X editors.

If the database expects the path to an asset to end in location X - and you've dragged that asset to location Y - the database will be hosed.

So it's always best to use the internal X "MOVE" Command to transfer projects and events between drives. Preserving the location relationship data is CRITICAL to X functioning well.

Hope that helps.