[Joe Marler]

[Brett Sherman] “I do a lot of cross library editing, and this is a fairly common bug.”

I have personally not seen this but I don’t do that much cross-database editing. I do often drag/drop a project from an externally managed library to an internally managed library for archival backup, and that has always worked. He might try that, but it definitely can take some space.

The overall data integrity of FCPX is very good but there are significant media management issues that need work — especially involving proxies and the inability to relink those.

[Joe Marler]

Is this the same library with 13k clips where you previously had problems? If so that’s pretty big. The largest doc I’ve done was 230 hr of 4k H264 material, 8,500 clips, 20TB in a single externally-managed library, about eight events. That was on a locally-attached Thunderbolt array. It mostly worked OK but you often see odd things at that level.

If it’s a different library and project from the prior problem, please describe any relationship between them. Did it inherit data from the previous one, if so, how? If it’s a different smaller library with only XAVC-L and iPhone material, I’m curious why *another* odd problem would happen.

This is 10.4.4, right? What media hard drive and machine type? Is it a locally attached HFS+ volume or on a NAS? Did you ever manually delete, add or alter any symlinks or other content inside the library? If so what was the immediate result?

Is the current problem isolated to just clips from one project when it’s copied to another library? Or are there non-project red/black clips in the source library’s Event Browser? When you copy the project to the other library, do you have optimized or proxy media? Did you select those checkboxes?

What if you make a project snapshot in the source library, open it, select all clips on the timeline, then delete all effects with Edit>Remove Effects, THEN copy that test project to the new library?

FCPX apparently uses Spotlight indexes to accelerate lookup, so I recommend you do a Disk Utility First aid on all volumes (inc’l system drive), verify no errors, then rebuild all Spotlight indexes on all volumes (inc’l system drive). Procedure: https://support.apple.com/en-us/HT201716

There’s not a high probability this will help but it’s easy to do. I know this is very rudimentary but also make sure you have adequate free space on all volumes.

I suspect it’s some kind of internal library corruption problem caused by a previous crash or who knows what. How was the media imported? Was it copied from the camera card to disk then imported using “leave files in place”, or imported from the camera card?

Can you describe anything else about the problem history? Did it start happening after a crash, after a system update, after a hardware config change, after you passed 10,000 clips, etc? Was it one or two black clips that got more prevalent? Or did everything look and work fine until you tried to copy the project, then you saw it for the 1st time?

What if you create a test library and drag several “problem” clips there (between libraries). Does it happen then? What about after consolidation, or if that test library is on a different locally-attached physical drive? What if the test library uses only internal storage?

What if you create a test project in the original library, copy/paste a few problem clips from the original project, do they stay black? If so what if you drag/drop that smaller test project to a new test library.

Sorry to recommend so many different investigative steps but I haven’t see this before and am just trying to “feel out” the problem boundaries and behaviors.

[Joe Marler]

[Jiri Fiala] “I have perfectly fine Project in Library A
-I create new Library B
-I drag Project from A to B

I get seemingly random black clips that reveal and play in Finder fine, not in FCPX. “

They don’t play in the FCPX viewer, or they play but thumbnails are black? If you right click a black clip and pick “Reveal in Finder” does that point to the media location you expect?

If you select each library in the left sidebar, then look at Inspector, is the media volume and folder what you expect? Are by chance both libraries sharing the same cache folder?

Is the playback anomaly only when using proxies or when using original media?

Have you installed Pro Video Formats 2.0.7? In Mojave that is in System Preferences>Software Update, for earlier macOS versions you get it here: https://support.apple.com/kb/DL1947?locale=en_US

[Joe Marler]

[Bill Davis] “I had a spate of crashes with a particular project too.
Finally figured out it was a toxic font. “

I had another FCPX crash today. The crash log indicated it was the Imagenomic Portraiture skin-processing plugin. In this case I didn’t even have a project open with that plugin, I was just importing a few stills.

You could argue that’s not Apple’s fault — their code didn’t crash, it was the 3rd-party plugin that crashed.

However when a software developer (Apple in this case) uses a non-sandboxed plugin architecture, the 3rd party code is running “in process”, or within the address space of the host app (FCPX). Any error by any plugin can crash the entire host application. The more plugins, the greater the chance of a crash, since they must all be perfect to avoid crashing the host app.

I don’t know what plugin architecture Premiere uses, but some of the crashes could be similarly due to 3rd-party code.

10.4.4, Portraiture build 1203, macOS Mojave 10.14.2, hardware: 10-core Vega64 iMac Pro

[Joe Marler]

[Oliver Peters] “Often the biggest culprit is the crappy media formats that are rampant in our business. While Premiere generally does well with native media of mixed sizes, codecs, and frame rates, that’s often not the best or most reliable way to work. “

Good point. This is one reason all NLE software tends to be more crash-prone than other software. It’s like designing a car to run on 20 different types of fuel, none of which are filtered at the pump.

Why not filter it in the car (ie NLE)? Because (1) Checking each one costs performance and (2) The video header items often don’t have simple valid vs invalid ranges. A good example is the metadata atom called “fiel” which is crucial to handling interlaced video. This is often mishandled by software. The complexity of the definition on table 4-2 of this page helps understand why: https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-BBCBACAB

Usually NLE designers hope for the best and assume the “fuel” their software engine runs on is pristine. When it gets “contaminated” or is poorly formed by previous software, the downstream app can become unstable or crash.

Also the NLE is pushing all aspects of the underlying platform really hard — CPU, GPU I/O, etc. In general my experience is FCPX seems a little more reliable than Premiere, but I’ve sometimes had FCPX crash five times a day for weeks. FCPX is critically dependent on the library database, yet there is no integrity checker utility like there is for client/server databases or even Lightroom.

[Joe Marler]

I imported 1080p AVCHD from an older Canon camcorder a few days ago. I don’t remember which one, maybe an HF-G10. It worked fine. This was on an iMac Pro running FCPX 10.4.4, macOS 10.14.2, and Pro Video Formats 2.0.7.

If you have not installed Pro Video Formats 2.0.7, do that. Starting with Mojave you do that from System Preferences>Software Update.

In general I recommend externally re-wrapping AVCHD with EditReady, then importing with “leave files in place”, but direct import from the on-disk AVCHD bundle seems to work with 10.4.4. As always, bare AVCHD files should never be copied outside the bundle and imported.

[Joe Marler]

What version of FCPX and macOS? What is the history of the proxies? Are they FCPX-generated proxies or are they camera proxies you somehow were using in FCPX?

Are the proxies stored within the FCPX library (the default) or were they moved elsewhere?

This is a basic question, but is there 20% free space on the system drive and all external drives? If nearly out of space it can make applications crash.

Is the media on the same volume and path as when the proxies were first generated? Unfortunately there is a limitation in FCPX where the volume name when the proxies were generated is stored in the library, and proxies cannot be relinked. I haven’t seen this cause a problem when switching back to original media, just mentioning it.

You could try creating another library, then copy the project (without proxies), then open that copied project, switch to optimized/original mode and see what happens. Using a new library sometimes helps. Note: before you copy the project, click on the new library, then open Inspector, click “Modify Settings” (don’t change anything) and inspect the current storage location. By default FCPX will use the previously-clicked storage location (if external) and you can accidentally end up storing new library content in the previous library’s on-disk location. If that works in opt/orig. mode but the clips are red, you can then relink.

[Joe Marler]

[William Schelhas] ” I have had Hard drives REPEATEDLY disconnect incorrectly and have trashed 2 brand new drives….Hard Drive through the IOGEAR hub….

Many USB-A hubs don’t support enough current for certain bus-powered portable drives. This will cause those drives to unpredictably drop off line, possibly damaging data if transfers are in progress. The review sits for the IOGEAR hub have many complaints about this.

Probably the most reliable option is getting individual Apple USB-C to USB-A adapters. There may be other hubs which work better, but most reviews are superficial. Almost no reviewer uses instrumentation to monitor or graph power/current consumption during various operations. Most hubs use a chip set which only supports 900 milliamps peak, and several portable drives draw more than this for certain operations. It can be very unpredictable — on drive might work and another not. It might work with one drive plugged in but not two, or might work until they are both seeking.

This doesn’t happen when they are plugged into an iMac or a 2015 or earlier MacBook Pro because the USB chip set Apple uses can supply more current. On 2016 or later MacBook Pros, the USB-C ports can supply plenty of current — provided no sub-standard hub gets in the way. A chain is only as strong as the weakest link.

[William Schelhas] ” …I now have 4 projects on my Macbook and the 1tb drive is almost full. I have to purge something. Is it safe to move the fcbundle files to another drive to archive? Do they contain all the material I need to reopen the project if I need it?”

Normally you can move a library and (if external media) it will reconnect. If the library uses managed internal media it is self contained. There can be libraries which contain both types of media. Media management in FCPX can become quite complex. I strongly recommend you get the Ripple Training tutorial on FCPX 10.4 media management. It covers all these areas, including proxy-only workflow:

https://www.rippletraining.com/products/final-cut-pro/media-management-in-final-cut-pro-10-4/

There are some useful 3rd-party tools such as Final Cut Library Manager: https://www.arcticwhiteness.com/finalcutlibrarymanager/

And Reference X: https://www.fcp.co/final-cut-pro/news/2038-copy-media-out-of-final-cut-pro-x-with-reference-x

[Joe Marler]

I saw this behavior once. The behavior was that either rendering or exporting would halt at a certain timeline point. There was no apparent error — it just quit. Zooming deeply into the timeline showed a few anomalous black frames at the halt point. I vaguely recollect those could not be deleted or after deleting them the halt still happened at the same timecode. I made a copy of the project and it still happened, and likewise after removing all effects. Deleting and re-adding the clip from the Event Browser didn’t work. I had to re-import the clip under a different filename, match timecodes for the edited range, then copy/paste effects from the original clip.

I suppose I could have tried exporting the project XML and loading that in a test library, but I didn’t do that.

That was about a year ago. I don’t know the cause, but I had previously experienced numerous FCPX crashes when adding multiple color corrections with the scopes up. It’s conceivable one of those damaged the library. The MacOS Core Data APIs and underlying SQLite database probably don’t have perfect transactional integrity. Unfortunately there is no library database integrity checker like in LightRoom or other client/server databases. I haven’t seen the problem since then.

[Joe Marler]

That was an interesting approach, thanks for sharing that. However he describes “only your best handheld/gimbal bits”, then says “pull clip to the timeline…sync by waveform”. In the timeline there is no way to sync by waveform except visually, so this would only seem practical if the gimbal and handheld cams were running continuously. In all the documentaries I’ve edited, the gimbal and handheld cams are running start/stop, plus they usually only have low-quality audio. Visually waveform matching one long clip with low quality audio isn’t that hard — eventually somebody will slam a door or something. But visually waveform matching a bunch of short clips with low quality audio is very difficult.

I think in Paul’s case his cameras are running continuously, so this method of using timeline markers on the favorite ranges could work. It’s worth a try.

The developers of the MergeX utility are working on an upgraded version which could take new clips (maybe favorite ranges) added after the timeline is edited, then synchronize them on the timeline. They don’t have a release date for this version, but the current version is quite useful in other ways: https://www.merge.software/#mergex

Until that is available, the best approach is probably sync the material in a multicam first, mark favorites and keyword ranges on the multicam — NOT the parent clips — then add those multicam ranges to the timeline. Within a multicam clip you can’t favorite an individual camera angle, only the range. However it’s visually obvious to most editors why the favorite range was marked. In list view the multicam favorite could be renamed to say cam1 or cam2; not sure how practical that is since it’s only usable in list view.