Is it Adobe or Premiere Pro?

[Steve Connor]

[Oliver Peters] “you can’t use a laptop as a good measure of best performance.”

Yes, but as a reference point it works, both Resolve and FCPX work well with XAVC on my system. PPro doesn’t.

[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.

[Bill Davis]

[Joe Marler] “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.”

I had a spate of crashes with a particular project too.
Finally figured out it was a toxic font.
Switched all instances of that font to a similar one – and the constant crashing stopped.

These are complex interdependent systems. A problematic system could be caused by a a storage access issue, a hardware issue,, a RAM issue, or like in my case. a semi-toxic bit of code that rides along with one third party version of something like my font problem.

Oh well.

Creator of XinTwo – https://www.xintwo.com
The shortest path to FCP X mastery.

[Tony West]

[Steve Connor] ” I REALLY missed FCPX’s save function when it did happen.”

I’ll will give X credit, in the times it has crashed I have never lost anything. It’s always come back up from day one.

[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