Working with a big library in FCPX – Loading Projects you don’t need

[Joe Marler]

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: https://www.arcticwhiteness.com/finalcutlibrarymanager/

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: https://support.apple.com/en-us/HT201716

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: https://support.apple.com/en-us/HT203477

You could also delete your render files using the procedure mentioned here: https://support.apple.com/kb/PH12704?locale=en_US

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.

https://www.girafxmedia.com/index.php/2016/09/08/fixing-corrupted-final-cut-pro-x-project/

[Joe Marler]

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.

https://www.fcp.co/final-cut-pro/articles/2121-refuge-in-the-heartland-a-case-study-in-shared-workflow-with-student-editors

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.