final cut pro 12.3 is failing to render to network shares

This error shows up in a DuckDuckGo search and joema responded that it appears to be an out of space error.

Final Cut Pro error -536870181 - Apple Community

I consistently export segments larger than 8GB to an SMB NAS without issue. Have you done any investigation to see if there are network issues?

I think posting an anonymized report of the system would be helpful for us to help diagnose your issue. Post a report from https://etrecheck.com using the "Additional text" button below in your reply. This app consolidates a bunch of anonymized system reports that can help to identify issues. Common culprits are "cleaners," the old Google Keystone autoupdating daemons/agents, and old software that has been migrated in place when MacOS upgrades are performed.

We work off of NAS so I don't have any direct Mac-to-Mac large transfer use cases. I believe @joema's facility works from local storage suites, not NAS, so maybe he's done large transfers between Macs. There are likely others here with setups similar to yours that can chime in. @BenB?

What do iperf3 tests show? Are all clients using the same MTU size? Jumbo packets? "Full-duplex,Flow-control," not "Full-duplex, energy-efficient-ethernet" set for the NICs? StudioSysAdmins was a good mailing list but now they're Slack only, so if you do Slack you could also ask there.

sysctl can affect network transfer by tuning kernel network parameters that control buffering, queuing, congestion handling, and socket limits, which in turn influence throughput and latency.

You need to make sure that the transfer is 16GB or larger (preferably using a utility like AJA System Test), and you will see that the transfer pauses after almost exactly every 8GB. This has to be over a 10G link as well.

To an SSD, this pause will be negligible, but it is still there, and you can see it on a graph pretty clearly.

It was a long time ago (for me), I don't remember the exact topology, but I know for a fact that I never had a 10G connection on that 2010 Mac Pro. It was over a 1G connection to a Mac network share somewhere, and FCP would cancel its render with the same sort of error every time. Basically the same thing this thread is about, but with smaller files and a slower connection, meaning the 8GB thing wouldn't be a thing, only the FCP bug.

Coming back from the Promise US headquarters, we brought back this PegasusPro thing, which is basically the Pegasus32s I already have, but with a NAS built into it. I've configured it to only have a NAS storage pool on it for now, put some test drives in it that are 12 years old, and I'm doing a quick FCP test.

I'm accessing the NAS pool volume thing over the 10G network, with the same source media on it that I've been trying to work with for 2 weeks. I'm exporting it to the same volume (because there's nothing else big enough other than Mac-hosted network volumes right now), and I'm suspecting it's going to finish successfully, because the host is not a Mac, only the client.

I'll let you know.

Thanks for that info.

I've now got my own 10G net setup and have done extensive testing, using both APFS, HFS+, mechanical and SSD storage on the M1 Ultra Mac Studio server. My client is an M1 Max MBP16, both running macOS Tahoe 26.6.2, and FCP 12.3 on the client.

In some of my tests, I used ProRes 422 LT material, exporting to ProRes 422 HQ, just like you. However, I cannot make it fail, no matter what.

In Finder, I can copy about 850 megabytes/sec between client and server, so the network and disk I/O is good.

It appears there is an inherent encoding performance limit for ProRes 422 HQ, roughly about 90-100 megabytes per second. If this is correct (I have some doubts, about this, still testing), it implies there is little to no benefit to 10G in the network encoding case. A 1 gigabit/sec network could handle that. Of course, the faster network is useful for copying files.

There is a possible "no encode" case where FCP can write at very high bandwidth. On my hardware, that's nearly 1,000 metabytes/sec. This is when the timeline, render format, and export format are all the same, e.g, if they are all ProRes 422. In those cases, FCP simply gathers source and render cache segments, concatenates them, and writes to output without encoding. So this is not very commonly used, but it is a good stress test of FCP writing rates across 10G ethernet to a server. I tested some with this and saw no problems at an approx 800 megabyte/sec writing rate from FCP to 10G to SSD storage on the Mac Studio.

See attached graph of server-side writing rates by an M1 Max MBP16 running FCP, exporting ProRes 422 HQ via 10G ethernet to a shared Thunderbolt 8TB 7200 rpm single-spindle mechanical HFS+ drive on a M1 Ultra Mac Studio, plus a 4-hour test of multiple FCP exports via 10G ethernet to various SSD and mechanical drives on the Mac Studio.

<I removed this becase I caught some possible issues and I need to re-test>

Wait a minute! There seems to be a basic problem here right from the start. minecraftiaMACUser100 said, “The source is ProRes 422 LT right now, and I'm trying to export it to ProRes 422 HQ.“

My question is - WHY?

Upsampling a ProRes422 LT file to a ProRes422 HQ file doesn’t improve anything. It just makes the file larger. But the fundamental ProRes422 LT source data is still the basis for this new file! So you are not gaining anything by doing this.

You can’t make something out of nothing.

I don't want or need to disable indexing, I plan to use spotlight.

As explained earlier in the thread, the Studio (or whatever destination Mac) does not start writing anything to disk until right before the 8GB mark if the transfer is going 10G line speed. Because of that, it starts thrashing the disk after that, forever. It's chaos.

This is a real problem, a bug in MacOS. Please, SOMEONE with 2 recent Macs that share a 10G network together PLEASE come forward so that it doesn't look like it's just me that has this problem..

I've just been informed that the OWC Atlas is probably the CFX card reader I have. This is moot since the largest card I have for that is 2TB.

A few days ago I just had a modern Mac storage professional tell me in person that APFS is still a bad idea for HDDs. Based on my own experience, I think this is still true, and don't trust APFS, plus it is overcomplicated. I'm sure Apple recommends it more than anything else, that doesn't mean it's a good idea.

The bottleneck is the MacOS 8GB bug, given that it still fails to render to any SSD or HDD based storage over the network. It doesn't matter what I wr- I'm just talking in circles, people that are new to this thread, please read the previous posts we have made as to not make me repeat myself 5 times.

Well it could flush the cache fast enough... if it even tried to in the first place. The problem is that it waits FAR too long, causing chaos. It can flush it at 1300MB/s, but it won't try until the 8GB thing, and after the pause, it'll start transferring again which causes HDD thrashing. FCP is just writing data in a certain way that this kills somehow. Finder copies are half as quick as they should be past 8GB, but they do at least work.

That's what I'm trying to get. A fix for either FCP's data writing nonsense, or MacOS's 8GB network bug. Preferably the network bug, but nothing can ever be that easy..

I think just transferring TO any Mac causes this, even if its from a Windows machine or something. Lemme test that.

Edit: IT HAPPENS FROM A WINDOWS PC TO A MAC AS WELL

Video

I have just collected the same logs you have for the Studio and laptop, but for the following scenarios:

-Mac mini M4 with 10G Sabrent NIC exporting to a not-yet-seen-in-this-thread HDD RAID5 volume on my laptop.

-Mac mini M4 with 10G Sabrent NIC exporting to yet another volume we haven't tried in the thread yet on the Studio.

There are like 2 other Macs I could use in like 6 more combinations, but I think this proves my point.

This proves to you that this problem is widespread across all Macs and has nothing to do with MacOS beta whatsoever.

The logs are in that WeTransfer thing you provided.

All the Mac mini there is doing is very slowly serving 7 other machines over the network from its own RAID box. This has no visible impact on network performance, because it's so insanely slow. Of course I don't just have 10G-equipped machines sitting around not doing anything, we are not in the interest of wasting money. Not that it matters anyway since this FCP problem happens regardless of what the 2 Macs are (past 10G) or what they're doing, I just wanted to shoot this nit down before it got picked.

Thanks, this is helpful. Yes the procedure you entered (however simple) is useful.

Re Apple not fixing filed bugs, some I filed years ago have not been fixed. Others have been fixed fairly soon. The fastest ever (FB10671041) was four weeks from me filing it using the macOS Feedback Assistant app to release of a tested, localized "point update." That bug was so important that Apple released FCP 10.6.4, just for that one fix.

But that timeframe was not typical; it was extraordinary. Other bugs I've filed that I personally think are important may be fixed on a longer timescale. So just because an issue is "near and dear" to us personally doesn't mean it will be fixed rapidly.

Re your situation, when I said above I think the behavior might be by design, I'm not passing judgment. That was just my early tentative technical assessment, which is subject to change as more testing is done. The reason I'm so involved here is that I still suspect this might be a significant code issue with broader impact. In the early stages of an investigation, it's possible to hold within your head two conflicting possibilities.

But this raises an important issue you might be able to shed light on. When you say you can't get any work done until this is fixed, does that imply this didn't happen before, and that it began in a certain version of macOS or FCP? If so, please explain. Any information about an issue beginning with a certain version is critically important, because from a source code standpoint, the devs can diff between the versions of the involved frameworks and review the code changes. That can lead to a more rapid fix.

Did this problematic FCP export behavior on 10-gig Ethernet to network storage ever work better? Or has it always been like this? If it ever worked differently, what macOS and FCP versions were involved?

Final Cut Pro does not throw any error, it doesn't let me know the render failed in any way. I had to figure this out on my own, being extremely confused, hours later, why my export wasn't where I told it to put it. This happened about 10 times before I actually sat and watched it, and sure enough, it just... stops "sharing"/exporting randomly.

Oh my god I finally found the Final Cut Pro export errors!!!

I wasn’t getting the notifications because my laptop is almost always in Do Not Disturb mode, and apparently these errors qualify as being able to be knocked down by that.

Here’s one of them:

I have no idea what this means.

There is no out of space problem. The volume has more than 40TB available.

NASs don’t seem to have this 8GB thing, this is a Mac problem.

I’ve gotten all of this crap to happen on a network that is literally my 10G NIC on my laptop connected through one Ethernet cable to the 10G Ethernet port on my Studio. I think we can rule out network degradation problems.

I specifically go in and disable browser auto updaters, and I don’t get suckered into “cleaner” type apps.

This 8GB problem happens across 2 machines that have near fresh installs of MacOS as well, so I don’t think it’s a migration thing. This was 2 Mac minis one with a 10G NIC attached and the other with an internal 10G Ethernet port, neither of which were mentioned before here.

I will attempt to do that report thing when I get back home.

I just came from the Promise headquarters, Mr. Payne and I were trying a bunch of things out as I demonstrated this problem to him in person. That is why a bunch of stuff looks like it broke, because I intentionally was force quitting things because I was in a time crunch. Has nothing to do with the problem at hand.

Remember when I said that this happens on EVERY Mac I own that’s fast enough? No other Mac I own has a Plex server running on it. That’s clearly not a problem.

Plus it never uses more than like 2 cores, and rarely uses all of 1. I did just add a new folder to it, so that’s probably what it’s busy with.

I need legacy software for a lot of the things I do. My laptop is my production machine for the most part, especially for this, since it’s the only Mac I own that has an HDR display.

The disk related spotlight and stuff that’s all built-in MacOS indexing, that’s all fine, and it goes away pretty quickly. I had only been booted for like 5 minutes when I generated this report (another time crunch), and I have more than 200TB of stuff, so yea it’s gonna take a while.

I already have isolated the problem(s). They are Final Cut Pro and MacOS’s network file transfer bug. I’m posting here to figure out how to fix these. There’s nothing wrong with how I have things set up, per my mention that 2 brand new Macs do this too.

I have no idea what the sysctl thing is about. Not what is causing any of this though.