Is FCP ever going to sort out the “large project file” crash problem?

[Jeremy Garchow]

I agree wih Shane.

You don’t have to transcode everything to ProRes, but working in a full raster ProRes timeline does seem help.

[Ben Holmes]

I don’t believe this is an XDCam problem – although I suppose it could be long-GOP related. I have a number of very stable FCP systems running latest versions on Leopard, for my money the most stable platform still. In general use, they crash very rarely. The systems are used most often stand-alone with external RAID5 arrays, plenty fast.

All, however, have issues with large projects. Mostly these use a lot of P2 rushes. However, I would add that in this case, it was rushes TRANSCODED AS PRORES on ingest.

My take on it, based on a lot of observation is that FCP does not like a lot of individual media files in a project, whatever the codec. This means that if you capture from tape, so have much fewer, longer (30 minute) clips, you will have fewer problems than if you have 100+ clips per hour of capture – even if you have the same hours of media total.

Think of this as the ‘database size’ of the media. Here, the project with 2000 10-second clips is far less stable than one with 50 30-minute ones. Note – this has little to do with either project size, media length or codec. It’s just the amount of different items FCP has to reference. I’d imagine (knowing little about software programming) this is due to the amount of limited memory FCP can use, and having to use plenty of it to keep a track of the media.

If this is the case, I suspect the issue will not be resolved until a 64-bit version of FCP exists.

A possible solution is to keep all your media in a reference project, with no sequences, and only open it to copy/paste the media you need into your ‘working’ project. We’ve used this work-around a number of times to skirt this issue.

FCP HAS to deal with this issue (and others) if it’s to close the considerable gap between itself and AVID in media management.

Edit Out Ltd
—————————-
FCP Editor/Trainer/System Consultant
EVS/VT Supervisor for live broadcast
RED camera transfer/post
Independent Director/Producer

https://www.blackmagic-design.com/casestudies/detail.asp?case=therydercup

[Tony Silanskas]

[Shane Ross] “Don’t use and XDCAM sequence. Use all that footage in a ProRes sequence and things will be much more stable.”

This is what I do if I have to work with XDCAM footage and can’t transcode, but it has never been “much more stable” for me. It crashes less but still a bunch. Gets slightly better once everything is rendered to ProRes in the timeline, but for cutting roughs this isn’t really an option.

tony

[Chris Dixon]

Thanks for all the very helpful feedback everyone!

[Jeremy Garchow]

[Ben Holmes] “Mostly these use a lot of P2 rushes. However, I would add that in this case, it was rushes TRANSCODED AS PRORES on ingest. “

See, i find the opposite. I use P2 a lot, but I use MXF4mac QT Import to bring in everything natively. This past summer we have a few pretty decently big projects and we had nary a scratch. It was completely solid, but I think I-frame MXF had a lot to do with that.

[Ben Holmes] “This means that if you capture from tape, so have much fewer, longer (30 minute) clips, you will have fewer problems than if you have 100+ clips per hour of capture – even if you have the same hours of media total.”

While it si true, the more clips, the more sequences, the more physical objects in a project, the more bloat there is, but also being able to reliable recapture is essential. Capturing a tape in one go is risky to me. To each their own, though.

[Ben Holmes] “If this is the case, I suspect the issue will not be resolved until a 64-bit version of FCP exists. “

And then we get to deal with the next round of bugs. 🙂

Cheers,

Jeremy

[Walter Biscardi]

[Chris Dixon] “I’m on v6.0.6. using 150+GB of XDCAM footage. The project file is 15.4MB. I can’t even attempt to scrub through the timeline or even think about viewing a bin as icons without a crash.
I will try breaking my projects into smaller ones, but has FCP fixed this on the newest version?”

That’s a really small project overall. Our documentaries run in the neighborhood of 100+MB project files and each documentary is broken into 3 or 4 projects.

We’re also running between 4 to 8TB of media for each documentary.

Each Mac has a minimum of 12GB of RAM.

So the fact that you can’t scrub or view items in a bin tells me you’re using underpowered or maxed out media storage arrays. We’re running 32TB of shared storage and another 16TB of local storage for four edit systems. It’s more than we need at the moment, but that means we don’t fill the arrays up. There’s always at least 25% overhead still left on the arrays to ensure maximum speed both for playback and for simply using the application.

Our projects can take a while to open but once they are open, we don’t have scrubbing or playback issues.

Walter Biscardi, Jr.
Editor, Colorist, Director, Writer, Consultant, Author, Chef.
HD Post and Production
Biscardi Creative Media

Register now for our Open House March 5

Blog Twitter Facebook

[Brad Steiner]

I think it IS very much an XDCAM problem. It’s just not universal, so someone can always say “I’ve been using bla bla bla for years and haven’t had a single problem…”

I don’t think it’s a size of project issue so much as a number of thumbnails. larger projects have more bins, more sequences, more for FCP to sample and choke on.

Look up the threads for years back. My question is, of all those before who’ve noticed this, have they found a fix? Has anyone heard from Apple?
I’d rather not take it to apple as a single incident and have them tell me to go through 20 things that others have gone through already…

Praise to the COW

BrAd Steiner
ImageWorks Media Group

[Tony Silanskas]

I’ve talked to Apple a few times over the past couple years, along with AJA and some other hardware manufacturers and have gotten mostly the same answers that are already in this post: Long GOP and Final Cut still has issues, turn off thumbnails, convert to ProRes, update to latest drivers of everything, hold breath and hop on one foot. And I agree with some that it seems worse with Snow Leopard than Leopard.

tony

[Brad Steiner]

It is most definitively worse with Snow. We were doing work for YEARS with XDCAM timelines, and only recently has it become a nightmare.

Sigh.

Praise to the COW

BrAd Steiner
ImageWorks Media Group

[Daniel Frome]

I’ll also chime in here:

It’s not just long GOP. It’s a project size issue. Whether you’re editing dvcproHD, XDCAM, whatever, we found that the bigger the .fcp file the more frequent your crashes will be. Having lots of RAM won’t solve the issue, since FCP is a 32bit application and will only use/see about 3.5GB of RAM.

We found while editing dvcproHD footage we could get to about 50MB projects before crashes started to occur. Projects that were 100MB in size crashed so often that they were not usable. In between the 50-100 size there was generally a linear correlation of stability/size.

The tollerance for long GOP projects is worse, but I can’t say for certain how much worse. Either way, any project less than 50MB shouldn’t be of any huge concern.

How will Apple fix this? A 64bit re-write will not completely solve, but should help increase the threashold. The issue is somewhat unavoidable due to the nature of how fcp stores its information. Looking at the new Premiere CS5 (which shares much of the same project architecture) we can see that the 64bit code does indeed allow bigger projects that don’t crash. We should hope that the same will apply to FCP.