Serious Multicam problem in FCPX 10.0.4

Multicam may have been implemented in Final Cut Pro X, version 10.0.3, and improved in 10.0.4, but working on a show that’s destined to be broadcast to License payers, I found it’s led to a new problem that could mean the loss of an awful lot of work. Of course, back-ups were also introduced at some point, but restoring from back-up doesn’t help if the back-up is just as corrupted as the current version.

The show featured a lot of live music. It was a holiday weekend, and I’d taken the work drive home to get ahead of the game a little. The situation arose when I’d made lots of lovely multicam clips of the performances. Each had one big clip of the live vision mix of between 45 minutes and an hour, plus two additional angles for only those portions that I wanted. In legacy Final Cut, I would have needed separate multiclips for each portion, but in X I could have one multiclip for all. Nice.

Having made them all, I started laying down my project. Then, it crashed. It happened when I was trying to extend a placeholder. (Why placeholders are so tough on resources I’ve no idea.) This is where I admit that my old MacBook Pro isn’t officially up to the task of running FCPX. It had been, back at version 10.0.0, but 10.0.1 brought with it a ‘Graphics configuration not supported’ dialogue every time it opens. It still does open, and runs pretty well, even with multicam clips over a Firewire 800 drive. I’m fairly certain, though, that the crash that stared this whole thing would’ve been far less likely on a more recent machine. [1. That’s not certain, though, and even the 12-core, 12 Gb 1333 MHz Mac Pro at work will crash, you know.] I don’t know if background tasks were running. I had ‘Create optimised media for multicam clips’ selected in preferences, but as the clips were captured as ProRes422(HQ) they were optimised already, surely.

So far, no biggie. When I opened again, though, I found my multicam clips were populated with blank clips. Not gap clips, but clips that seemed to be all alpha, if you know what I mean, all nothingness. No warnings, no error messages, just wrong.

Not only that—they couldn’t be fixed. I tried replacing the clips in the Angle Editor, the way you can in the Timeline, but it just seemed to overwrite instead of replace, and then, immediately, crash.

Neither could I relink the clips from the Angle Editor—a much-touted ability as far as clips in the Projects and Events are concerned, added in 10.0.3.

Giving up on rescuing the clips, I tried to delete them, but whenever I did I got a one-two of error messages that I hadn’t seen before.

First this, that the Trash was somehow not ‘supported’.

Then the killer, that nothing could be saved, and that I better quit, pronto.

I should point out that I had 2.6 TBs available, moved no Events and recently checked the permissions. It was right, though: nothing stuck after the warning, not even after the old duplicate-project-to-force-a-save trick. And the Event in question always needed to be restored, although the back-up was increasingly recent.

On the umpteenth restart I simply made a new multicam clip, which seemed to work fine. I then tried to delete the corrupt one it replaced, only to be met with the ‘cannot save’ error. Making another multicam clip just for the hell of it, I quit manually. Another restart, another ‘restore from back-up’ message.

Neither new clip made it. The next time, I made a new multiclip, then manually quit before angering the Final Cut God by touching a corrupt multiclip. (Had to wait a fair while for the waveform to build, not knowing how the Final Cut God would react to cancelling it.)

I could tell from the ‘restore from back-up’ warning that the new clip hadn’t stuck—the back-up was the same one I’d used on my last restart, according to the timestamp.

So I made a new Event and dragged all the (non-corrupted) clips into it from the corrupted Event. Final Cut reported that there were ‘shared references’ between the two Events (presumably meaning that in couldn’t just move clips that were being used by a project) and that the clips would be copied. Despite the fact that the Original Media folder had only QuickTime References in it, and the option to copy media was deselected in preferences, all the media would be copied into the new Event’s folder. With 300+ GBs to copy that’s an overnight job at FCPX’s pace.

Or so I thought. In the morning, only 50% had been done, and with a screening at noon I couldn’t wait for it. Problem: it wouldn’t let me quit. It insisted that I’d have to wait for the media management task to finish. Would cancelling the task anger the Final Cut God? I’d soon know. Already 10 minutes late for work, and only 60% done, I force quit FCPX and relocated to the office edit suite.

Because I had a screening with the client, I forwent dicking about and just recreated my multicam clips in the new Event as quickly as I could and got the project ready for viewing. All temptation to play about with the issue on a more robust system was allayed with the promise that, after lunch, I’d go media management crazy.

The force-quit hadn’t ruined everything (thank Final Cut God). Curiously though, it made no attempt to restart the copying process. Also, although background tasks had been at 60% when I force-quit, the Finder reported that the new Event was less than half the size of the corrupted one (120 Gb compared with over 300). Opening the Original Media folders in each showed that the new Event was quite happy, all of a sudden, to use QuickTime Reference files for all the ones that hadn’t copied. Conclusions: copying clips to other Events creates references first and foremost, then replaces them with full-bloodied clips in the background as normal (a process you can interrupt without harming anything, despite what the dialogue box says); and the background task percentage in FCPX was determined by something other than file size, most likely number of clips (i.e. it had copied 60% of the number of clips, not 60% of the media as a whole).

In the Finder, I tried moving the corrupted Event’s folder into a different directory on the same drive [2. precluding actually moving the media from their physical locations on the hard disc], having shut down Final Cut. Upon reopening, I found that it seemed to know where all the clips had moved to, but in the Project Library the missing Event was flagged up. Confusingly, the Inspector now referred to it by its original name, not what I’d renamed it to within Final Cut. Not liking the nasty warnings, I quit Final Cut again, moved the corrupted Event back to the Final Cut Events folder and reopened FCPX.

Now, the Inspector for each project [3. I make dupes every so often as I do with sequences in Final Cut Legacy and Avid] showed the corrupt Event (back to the name I’d given it) as present and correct.

This is where the Modify Event References button at the bottom of the Inspector’s Properties tab came into play. The dialogue that opened showed all the events containing clips that appeared in the project. To my relief, it recognised my copied clips in the new Event alongside those in the corrupted one, and helpfully reported that, in the case of such duplicates, if I wanted to change which Event’s clips the project used, I need only drag that Event to a higher position on the list. When I did this, placing my new Event above the corrupted one and hit OK, the project immediately reflected the change. I was on my way to being able to delete the bad Event and get on with my life.

I couldn’t resist, though, one more try at just deleting the offending multicam clips and saving the original Event. The only thing that this would prove would be whether my old laptop or Final Cut Pro X itself was responsible for all those crashes the day before, all those funny ‘cannot save changes to projects or Events’ messages I’d been getting. Not the most useful information, and there was a risk that I was inviting the weird corruption back into my life, here on the verge of getting rid of it. Why I needed to know such a thing, I don’t know. I just know that I did.

I selected the first corrupted multicam clip, brought up the contextual menu and selected the last option: Move to Trash. The pointer turned to the spinning beach ball and then it came up. “Final Cut Pro cannot save changes to projects or Events. The disk where your projects of Events are located may be full or unavailable, projects of Events may have been moved, or permissions may have changed. To avoid losing your work, quit Final Cut Pro.”

I quit.

I restarted the machine, just to be safe. I opened Final Cut Pro X to check that my new Event was still good, and that my projects were dutifully referring to it and not the corrupted one. They were. Bullet dodged. I then shut down Final Cut, moved the corrupted Event out of the Events folder (but not off the disk—you never know) and started Final Cut again. All was well.

So I lost about a day to this nonsense, and a day that should’ve been a holiday at that. All I know now is how to modify Event references and that it wasn’t my faithful old laptop’s fault. Not entirely, anyway. But that knowledge, somehow, was worth it.