FORUMS: list search recent posts

Working with a big library in FCPX - Loading Projects you don't need

COW Forums : Apple Final Cut Pro X

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Jonatan Lyssens
Working with a big library in FCPX - Loading Projects you don't need
on Oct 25, 2018 at 10:53:30 am


I'm working a long project six year in the making. A lot of clips (1729 clips, same amount of audioclips and synchronized clips) about 120 hours of material, lots of projects (319). Nine out of ten, the library works fine, sometimes it takes a while to load the library or a project, but nothing dramatic. BUT one out of ten, it takes forever for example I clip on a folder with some rushes and FCP starts loading a ton of projects I don't need to be loaded, which aren't even in that folder. It seems very random and it takes forever. I'm taking 30 minutes or more. Until I give up and force stop the application. Reboot my mac and start again sometimes this works sometimes it doesn't. Really a lottery.

Does anybody have any tips to avoid these problems?

Technical details:
FCP 10.4.3
High Sierra
Imac Retina 2017 3,4GHz intel core I5 24GB 2400 MHz DDR4, Radeon Pro 570 4096MB
Drives: Lacie D2 thunderbolt 2 drives (2x 6TB) connected through Belkin thunderbolt dock

Return to posts index

Joe Marler
Re: Working with a big library in FCPX - Loading Projects you don't need
on Oct 25, 2018 at 5:28:55 pm

I've seen occasional sluggish behavior when loading large libraries due to loading many project snapshots, but I don't remember seeing it on regular projects. But then I've never had 300+ projects in a library.

I've also never seen it hang FCPX -- the worse I've seen is taking one minute to load vs 5 seconds. That was on a library with 8,500 clips, 220 hours, and 20 terabytes, but probably no more than 30-40 projects including snapshots. Hardware was a top-spec 2017 iMac 27 and four-drive 32 TB OWC Thunderbolt array in RAID-0.

If you have any AVCHD material whatsoever which was imported using "leave files in place" instead of re-wrapping, this can cause unpredictable slowdowns due to generating many small random I/Os. I don't remember it manifesting during project or library loading, but any such material should ideally be removed and re-imported using FCPX re-wrapping or externally re-wrapped with EditReady. Note externally re-wrapped material will have a different filename and characteristics so will not relink. If your film is using six year old material, it may include some AVCHD, so I suggest checking this. Usually the filename suffix is .M2TS, .MTS or .M2T.

The 3rd party utility Library File Manager allows exporting a .XLS spreadsheet with the name of each media file used in a library. This is one way to inspect the location and type of files used:

I'm not saying this is the problem -- it just came to mind. I have seen intermittent slow loading behavior on libraries with no AVCHD material but it was never really bad or hung FCPX. There can be some unpredictable referencing and loading of project snapshots, even when the user doesn't open the snapshot. It might be some kind of pre-loading or project pre-fetch optimization which bogs down library initialization when there are many projects or snapshots.

Make sure you have plenty of spare disk space on the system drive and media drives.

Another step which might help is rebuild all Spotlight indexes on all drives, including the media drives. Apparently FCPX uses these to expedite file access. I've seen cases where rebuilding these helps performance when loading a library or scrolling the Event Browser. Procedure:

While you're doing that you may as well run Disk Utility First Aid on all volumes, just to ensure the file system is OK.

A standard FCPX troubleshooting step is reset user preferences, which is described here:

You could also delete your render files using the procedure mentioned here:

However I'm not sure those are needed when loading the library. Also I think this only deletes generated render files, not other generated files stored in the render folder such as audio peak data and video thumbnails. Those are used during library initialization but I think the only way to delete them is the manual procedure mentioned here. Anything like these steps should be approached very carefully and only after you verify good backups, especially file-level backups of the library file.

Return to posts index

Joe Marler
Re: Working with a big library in FCPX - Loading Projects you don't need
on Oct 27, 2018 at 10:30:14 pm

The slow loading problem caused by many project snapshots is mentioned in this recent article. They state some libraries took 15 minutes to load. This was on an Xsan, so that may have been part of the problem.

The short-term solution was "created a clean library for the final timelines". Longer term maybe they will migrate to a higher-performance NAS like LumaForge.

If your media is all on two locally attached Lacie D2 Thunderbolt drives, the performance might be OK but ultimately those are "merely" single-spindle 7200 rpm drives. You have a very substantial library and loading many projects during library initialization takes lots of I/O, at least as FCPX is currently designed.

I suspect there is further optimization possible in future versions of FCPX -- I don't see why it's pre-loading so many project snapshots rather than load them on demand. I've seen it also do likewise for regular projects, but in my case (and the above-referenced case) it was snapshots. However until that is improved the solution is probably limit total number of snapshots, projects, improve I/O or copy the projects to another library.

In FCPX any project can reference any media within the library, so in theory you could copy your projects to another event. That doesn't copy any media. I don't know if it would speed up library loading, but you could try it.

Another possibility is copying some of the projects to another library, which will also copy associated media. However due to hard link optimization, if they (and associated media) are copied within FCPX to another library on the same drive volume, it won't take up any more space.

Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2020 All Rights Reserved