-
Pro Apps Crash Too Often
-
Ppro is buggy as hell for me. Way more so than FCPX and Avid.
Constantly lose audio – like it just stops playing and i basically have to close the sequence and re open to get audio back – a bunch of other little lame things like if I wiggle my mouse during playback I drop frames, etc.
I never have full crashes or lockups but so many little nagging things that make it a frustrating experience for me on the daily.
The other apps may lockup from time time or completely poof – but regular day to day editing is a smooth as youd expect from a modern NLE.
-
[Oliver Peters] “Mine’s much simpler than Joe’s. Simple timeline of selects. Pulling clips from 20 or more 30min. TV shows. ProRes masters with stereo tracks. Just fast JKL of the source (or skimming), then I and O and append edit. Simple, but in very rapid succession. At some point in this process, FCPX simply stops updating the filmstrip image and then locks. Hard.
“That’s a deeper system problem, surely? I do this sort of fast selects all the time with no issues?
\”Traditional NLEs have timelines. FCPX has storylines\” W.Soyka
-
[Steve Connor] “That’s a deeper system problem, surely?”
Except it’s solid in all other NLEs on the same system. Sometimes the media gets sluggish, but never like this. The real issue I have with X is very inconsistent performance. Sometimes it’s great and that lulls me into using it more. Then other times, like this, I get burned.
– Oliver
Oliver Peters – oliverpeters.com
-
[Oliver Peters] “Except it’s solid in all other NLEs on the same system. Sometimes the media gets sluggish, but never like this. The real issue I have with X is very inconsistent performance. Sometimes it’s great and that lulls me into using it more. Then other times, like this, I get burned.”
Nothing but sympathy for those sorts of inconsistencies. I’ve had eras where stuff was rock-solid for months – then suddenly got unstable. Might be a system change, a new aspect of the program installed during an update, or something as hard to figure as a corrupt font or graphics.
These are complex systems and crash causing bugs are a BANE on everyone.
I hope you get it sorted, Oliver. That’s totally no fun.
But it can’t be very common – because Apple just announced that X grew by a solid 20% since last years NAB and Apple is saying there’s 2.5 million seats now.
20% year over year owner growth just wouldn’t be happening if the largest adopters were facing a constantly crashing and an overall buggy experience.
Of course, that doesn’t lessen the pain when the person facing those crashes is YOU. But it’s a pretty good indication that it’s not so widespread that it’s hurting the software’s uptake.
FWIW.
Creator of XinTwo – https://www.xintwo.com
The shortest path to FCP X mastery. -
[Steve Connor] “That’s a deeper system problem, surely? I do this sort of fast selects all the time with no issues?
“I agree, that is awfully simple to cause a crash. Oliver, does it happen on more than one system, or mainly just one?
-
[Bill Davis] “Nothing but sympathy for those sorts of inconsistencies. I’ve had eras where stuff was rock-solid for months – then suddenly got unstable. Might be a system change, a new aspect of the program installed during an update, or something as hard to figure as a corrupt font or graphics. “
Thanks. I appreciate it. There are many possible reasons, of course. My biggest two suspicions are either the machine (2013 Mac Pro), which we all know is very “long in the tooth” these days, or the NAS. As I said, I’ve had better luck with direct-attached storage. The other element could be the latest OS update, which might have some issues, too. We’ll see.
– Oliver
Oliver Peters – oliverpeters.com
-
[Joe Marler] “does it happen on more than one system, or mainly just one?”
I don’t know. This install is a system of 8 Macs connected over 10GigE to a QNAP NAS via a switch. Mix of iMacs, iMac Pros, Mac Mini, and 2013 Mac Pro. There’s only the one MP and I’m typically the operator in that room. None of the other editors want to have anything to do with FCPX. So FCPX is typically only used by me on the Mac Pro, not the other machines.
I’ve had much better luck when I cut stuff on the attached Promise RAID (additional locally attached storage), but this media has to stay on the network. I’ve also had better luck when I transcode proxies, even though the source is only 1080p/29.97 media. At home, my MBP also performs well with FCPX (using local storage).
I’m at NAB this coming week, so I intend to have a conversation about these issues with the QNAP folks.
– Oliver
Oliver Peters – oliverpeters.com
-
[Oliver Peters] “‘ve had much better luck when I cut stuff on the attached Promise RAID (additional locally attached storage)…I’m at NAB this coming week, so I intend to have a conversation about these issues with the QNAP folks.”
This might indicate a system-layer problem, not one with FCPX. However the system layer (macOS and the driver stack below that) should handle gracefully any network or disk I/O issue. It should report an error, a timeout, etc — not crash or hang.
Unfortunately it is common for silent errors or unexpected behaviors in either network or disk I/O to destabilize an app or the system. There are various threading APIs in macOS, but essentially the app is submitting many overlapped, ie asynchronous I/O calls, so there are a bunch queued up waiting for a completion signal. Each of those must also handle exception cases such as completion too slow, timeout, abort from the app, etc. All data structures, memory, handles, etc. must be cleaned up in all exception cases for each pending I/O — even if a multiple exception happens. E.g, if the I/O is slow to complete then the app issues a cancel. All this must happen in a thread-safe manner.
The bane of software testing is these asynchronous exception cases where the backout code path must work perfectly, yet it is often difficult to trigger this using normal test suites.
Just because FCPX crashes in your environment and other NLEs don’t doesn’t necessarily mean FCPX is at fault. There are various software “load paths”, and FCPX might be stumbling into on. E.g, consider if there was a bug in the code path for accessing Quick Sync. FCPX might crash on this, yet Premiere would not since it doesn’t use Quick Sync on Macs. Something like that might be happening in the network I/O realm.
Your scenario happens when executing rapid JKL commands when the storage is on a specific type of NAS. That could imply it’s triggered by a certain I/O pattern in combination with some unexpected response or exception case from the NAS. If this was understood it might be possible to write a small multithreaded test program which rapidly reproduces the problem, hopefully leading to quicker resolution.
It would be interesting if you could borrow or evaluate a totally different type of NAS such as a Lumaforge JellyFish, put your data on that and see if the problem goes away, stays the same or whatever.
In my case I’m using several different Macs, different H264 codecs, different RAID arrays, and all local Thunderbolt storage. It happens over multiple macOS and FCPX versions, so there is no obvious commonality. It is loosely related to timeline complexity as number of edits accumulate.
The FCPX data integrity seems quite good, as I almost never lose any work, despite all the crashes. However I’m always concerned that a spate of crashes has injected some damaged data which then makes subsequent crashes more likely. Unfortunately there is no FCPX database verifier.
-
[Oliver Peters] ” This install is a system of 8 Macs connected over 10GigE to a QNAP NAS via a switch. Mix of iMacs, iMac Pros, Mac Mini, and 2013 Mac Pro. “
I have basically the same setup you do. And have similar problems. My sense is that the NAS/OS X interaction is the culprit. There just seems to be occasional weirdness. Losing write privileges suddenly, but rarely. Periodic beach balls are fairly common. My sense is that the more shared folders you are connected to, the worse it gets. Beach balls seem less likely when I’m connected to only one shared folder.
Reboots of the Mac seem to help. But I’d love to hear what you find out from QNAP. I plan on upgrading the QNAP firmware to see where that gets me. Then hopefully this fall, the next Mac OS. I’m on Sierra hoping to skip High Sierra.
-
[Joe Marler] “Unfortunately it is common for silent errors or unexpected behaviors in either network or disk I/O to destabilize an app or the system. ….. All this must happen in a thread-safe manner.”
I completely understand and agree. My frustration is that when the system becomes unstable, it seems to affect the computer much more under FCPX than other apps. As I said, if I simply waited out the hiccup, it recovered. But if I tried to Force Quit it became a major issue. I don’t have those same experiences when and if I have to Force Quit other apps. Hence the decrease in hair ☺
– Oliver
Oliver Peters – oliverpeters.com
Reply to this Discussion! Login or Sign Up