final cut pro 12.3 is failing to render to network shares

I don't want to be recompressing it (yet). ProRes is a lossy codec. It is "visually" lossless, but it's not actually lossless, but cmon do you want me to export in Uncompressed? That would be absurd. And a waste of time.

I'm going to be compressing these HQ files right after in Compressor to a high quality H265 version, one that I can actually store. Processing EVERYTHING to the highest quality file BEFORE doing that is the best idea. Doesn't matter what you start with, the point is to not be recompressing it 3 times before you even get to Compressor.

So I am gaining something. I'm gaining the finished HDR product before compression, in its best quality.

I'm not sure what iperf is... but we've done a lot of AJA System Tests. That is what Promise recommended. Here's a bunch I just compiled, I can't get to my 10G NIC right now, so I'm using 3 other computers to show this 8GB problem. One of these tests is even an external USB4 SSD on one of them. The 3 computers are my dad's Mac Studio, my Studio, and an M2 Mac Mini, all with 10G capability:

https://gofile.io/d/Z6vDH5gq

The last one I did was from my Studio to that M2 Pro Mac Mini, and that one wasn't going line speed even though I was testing it to its internal SSD, but it still hit the 8GB thing, just farther down the 16GB test.

Oh, that file might be interesting to mess with here then... except for the fact that it apparently doesn't exist on my Studio..? Idk what that's about.

Anyway, I did try all packet sizes, Jumbo, Standard, 16000. I also tried all of the ethernet modes, as in every option in the dropdown that energy-efficient-ethernet is in. I also tried enabling/disabling AVB/EAV mode. Nothing changed except the things they are supposed to change. Jumbo packets + full-duplex+flow-control seems to be the best combo I've found for general 10G network performance, but this 8GB problem never went away.

Oh I forgot to explain how to read the screenshots.

You can see a pretty consistent drop in performance on writes on the bottom graph almost always right in the middle of the 16GB test. The only anomaly is explained above.

If you are starting with ProRes422 LT, NOTHING you do to it is ever going to make it any better than ProRes422 LT.

There is no reason to go from LT to HQ and then start all your other processing. You should start the process with the LT file. You will achieve the exact same results, with far less processing.

It's not going to be better than the source, that's not what this is.. have you even done video for production purposes?

The point is that it will be THE SAME, as in, NOT RECOMPRESSED. LT is MORE COMPRESSED than HQ, therefore I want to export in HQ so that I can compress myself. Make sense?

Exporting in HQ is always better than exporting in LT, and that's a mathematical fact.

Unless you're going to tell me that because it's intra-frame this doesn't apply to ProRes? If it's re-encoding the frames AT ALL, that's bad.

Either way, it's moot since NEITHER will finish.

Is maybe what you're confused about here the fact that I don't seem to be even modifying the LT file before export? Because I am. I'm turning it into HDR to get as much depth and detail as possible before I compress. That is why I'm doing any of this.

This is why I requested that someone else post for me. I hate posting on forums, because almost no one seems interested in helping. Only nitpicking what I'm doing, and not actually why it isn't working. It's infuriating.

Props to you Terry for trying to help.

I don't know what an OWC Atlas is, but I don't have one. I do have 2 external SSDs, however they aren't big enough (as I've explained) to do these kinds of renders to. 2TB is pretty mild for me, often exceeding 8TB for one export. I know it would work, it's simply not an option. I could do that test, and it would succeed, but there wouldn't be a point in that, since it doesn't solve the problem.

Having the source local instead is way more doable, but the destination still has to be over the network, which of course doesn't work.

The Mac Studio has nothing to do with it, nor anything running on it. This problem happens on brand new Macs with fresh installs of MacOS, so it can't be anything I put on it.

I don't have an APFS SSD share anywhere, except for the internal Mac SSDs, which aren't big enough to test this with, and I can't just create a new one.

I treat all volumes as suspect. I used a tool called DiskWarrior (oh yea you saw that) to defragment the volume's directories. Sadly, I don't really have the luxury of keeping extra space on my volumes for stability purposes a lot of the time. After this problem is resolved, I can free up like 30TB though, so that'll be nice.

I was only thrashing the volume for time expedition. It does fail faster if I do that, however it fails every time if I don't as well, so the only difference is how much time it took to get back to you.

I know for a fact the network isn't the problem. I've said this many times as well. The core problem is internal to MacOS's network stuff, and Final Cut Pro is dealing with that so badly that it won't even export any large export successfully.

When I was at the Promise (Pegasus makers) headquarters, I was demonstrating to a support-handling guy this problem. He started talking about CIFS and other ways of mounting the volume to see if that had any different behavior, but of course it doesn't let you connect with that to another Mac, it's only for connecting other things that serve it.

I don't believe I CAN use anything else other than SMB anyway, so this is moot.

I disable gatekeeper and SIP because I do many things that they don't like and I find them extremely annoying, so security takes a backseat. I don't like my computer autoupdating anything for the most part, so I disabled that too. mds_stores is a built-in MacOS process, as well as apfsd. mds has to do with spotlight, and as I've explained elsewhere in the thread, I have many TB of data, so a lot of indexing is expected. The cracked source software is out of convenience, since we do have a App Store Logic license, I just have a locally stored copy and that's faster than downloading from the internet every time I need it.

This machine is the most reliable machine in the house, and it's as fragile as anything else.

Sadly, none of this helps.. Most of these comments were rendered moot earlier in the thread, and have been explained. I urge you to read through the thread if you would still like to help.

What I need is some setting in some hidden file or something that tells SMB or whatever to write to storage immediately when it gets data in through the network, because that is the root cause of this crap. Either that or someone needs to escalate this to whoever deals with MacOS bugs. This is a problem across ALL MACS with fast enough networking, and should be worth their time, especially since it is causing their Pro Applications to bug out.

A slow drive works fine connected locally, so that's wrong. In fact, there's stuff that's wrong all through this. The 10G link isn't a bottleneck because the VT can't get it processed quite that fast. It even says so in your response.. so I have to ask..

Is that mostly an AI generated response? If so, please stop using it, it's not generating helpful responses. Everything there has been rendered moot.

"A slow drive works fine connected locally, so that's wrong"

That's what I said. My exact words were "a slow local drive never does this."

"The 10G link isn't a bottleneck"

Correct, it's not a bottleneck. That's what I said. My exact words:

"the network...it isn't the problem"

I then elaborated, explaining that while *not* a bottleneck, the 10G network creates a timing condition that exposes this behavior. It coincidentally enables the problem, but it's not a bottleneck.

Your original diagnostic info is incorrect because I'm not rendering on an M4 Max, and it is FAR SLOWER than realtime when I export, remember this is 8K60 video.

The Pegasus I was writing to definitely has enough speed to write this data at the rate it is going, the problem is that the Studio is buffering for way too long. This nonsense is what causes FCP to fail on any machine doing this.

I said before it's possible this happens on non-beta macOS. It's not a matter of whether we believe it. The problem was that all the work and analysis of that data was based on beta macOS. None of that can be turned in or used in filing a bug. Apple will not accept a bug filed on beta software (outside of a beta program). It's a matter of policy.

Filing a bug is not merely an earnest assertion that a problem happens. It's hours (or days) of grueling work and methodical documentation in a specific format. You can see here some examples of past FCP bugs I've filed:

https://www.dropbox.com/scl/fo/ik63ud33fifnrjdctyr07/AJsb3pkrUuGPAcHSaZ5aD_E?rlkey=rjpbonkp78p4dvahsvhn9zl5s&st=vffuz5om&dl=0

The problem was time. The painstaking analysis done on beta macOS now has to be re-done. That's not a quick go/no-go test. It's hours of work. That cost us a day.

We're just end-users volunteering our time to help you. Thanks for sending this other info, I'll start looking at it today.

I did submit a report using the Feedback Assistant, which seems to have a connection to the betas, but I've filed like 10 bugs in there, and none of them got fixed for years, so I don't have high hopes for that. I've actually typed out pretty much what those bug filings look like for some of them, so that doesn't appear to be as grueling as it seems maybe to other users. I'm used to it. I also do testing for a few developers on the internet. The only thing I didn't do was give clear step-by-step reproduction instructions for the most part. That would be super simple to do for this one though, so I should go back into Feedback Assistant and add that.

If I'm understanding, the bug report filing is just.. explaining what the problem is, how it can be reproduced, and what the user tried that didn't help that reasonably could have. That's what I see.

I have the time since I can't really get any work done until this is resolved.

Edit:

BTW, I'm working to set up two Macs on 10-gig Ethernet to test. If I can reproduce this (and based on your information, it sounds possible, even likely), that will help a lot. I could repeatedly run the scenario while taking various diagnostic traces such as Xcode Instruments, which would support a detailed bug report.

Even if it did not reproduce on my end, that itself can be useful. We could then examine specific config or other technical differences between our setups. That itself could lead to a low-impact or no-impact workaround.

Good to know.

Yea the reason why I’m so **** bent on getting this known and fixed is because if this is a problem, then it’s a big one that likely causes more problems for everyone.

I have been filling up my storage with video files that I need to process down. I don’t have room for much more of anything now because of this. I’ve had to “borrow” additional HDD hardware from my father due to me running out of space. My plan was to use FCP to HDR-ize everything on its way to being compressed. I can’t get any work done because the files I’m stuck with until this gets fixed are very large, and they have to stay that way if I want to do this at all. I just… kinda forgot that FCP had this problem. It has for at least 5 years, ever since I started using it in 2021. I ran into it again in 2025 while at someone else’s house, and even deleted the original media I had before I realized that FCP had quietly cancelled the exports and I had no idea so of course I didn’t go check for the exported files until it was too late. That was terrible. I’m running into it now, and with media that can’t be made smaller until this is done.

I dont remember what the topology was before now other than that it was always failing when exporting over the network, or when the source media was over the network. Both of those have the same result.

To put it simply, I’ve had the problem on MacOS 10.13.6 on a 2010 Mac Pro with the latest FCP that runs on that OS, all the way to my 27 beta laptop running FCP 12.3. As far as I can tell, this has actually been a problem for 8+ years. The 8GB thing though.. I don’t know, since I never noticed it until I got a bunch of 10G equipped Macs with HDD RAIDs to go with them. It definitely makes the FCP problem worse.

To complete the list, I’ve also had the FCP problem on MacOS 12, MacOS 13, MacOS 15, and MacOS 26.