Final Cut Pro error -536870181

Folks I keep getting an error when exporting my timeline and wondered if anyone knew what this error is.


Computer Profile:

M2 Max MacBook Pro / 64 GB RAM / 2 TB / mac OS Ventura 13.3.1(a) / FCP 10.6.5


MacBook Pro (M2 Max, 2023)

Posted on May 8, 2023 6:50 AM

Reply
Question marked as Top-ranking reply

Posted on May 10, 2023 6:27 PM

Tangier, Davis' last post about disk subsystems got me thinking. Like you, I found there are almost no references to error -536870181. However -- converting it to hexadecimal = 0xE00002DB. Searching on variations of that hex number leads to the open source file IOReturn.h, which is part of the IOKit framework used in macOS. There we find:


#define kIOReturnNoSpace iokit_common_err(0x2db) // no space for data


IF that is correct, it implies some kind of out-of-space condition during an I/O operation. It's interesting the error happened when *exporting* a file (which obviously takes lots of space). That said, it might not be a normal "out of space" condition.


It could be some transient issue involving memory usage spilling to the page file (which takes more space but is quickly released). It could be APFS local snapshots consuming space, or even a problem with the drive itself.


Re the project repair function, I have a recent copy of your project (minus the media). I tried the repair and it found no problems.


We still haven't time-correlated the above errors from the system log with the "-536870181" error raised by FCP during export. We need to verify those are happening at the same time. Right now it's just a guess.


However I think the kIOReturnNoSpace error is a promising lead. An FCP user on Reddit reported that error -- also when exporting a file. He also reported logged errors referencing VTEncoderXPCService, which is the host process where the encoders run during export. That process itself can take up lots of memory, which can spill to disk in the page file.


Another complication is APFS has a "local snapshots" facility which can also consume space. I think it's supposed to release those when under pressure, but maybe the thread making the I/O call got tired of waiting and interpreted it as a failure.


I suggest you boot the machine in Recovery mode and run Disk Utility First Aid on each disk volume. To run it properly on the Macintosh HD volume, that should be expanded in the left sidebar of Disk Utility, then First Aid should be run from bottom to top, one pass *each* on "Data", "Macintosh HD", etc. Running it in recovery mode gives the best results because all other activity on the drive is stopped.


Disk Utility should update any space usage metadata that might be off. Then boot the machine, check disk space, take action as needed. Make sure there is *plenty* of extra space on all drives.


Once the system is up, I suggest running Disk Utility First Aid on all other drives. Observe the results of each pass, make sure there are no serious errors.


Yes, updated log only if you get the error again. I'd also like any FCP diagnostic reports from /Library/Logs/DiagnosticReports. You can go there in Finder via Go>Go to Folder (enter /Library/Logs/DiagnosticReports), then do CMD+F in Finder and search that folder for "Final Cut". Zip those files and send them to me, but only if you have another error.


If you have another error, please note the date and time (inc'l time zone) and let me know.

22 replies

May 10, 2023 5:36 PM in response to Davis_

Thanks for the input Davis. I purchased all new cables with my MBP and the CalDigit. I too wondered if one of the drives was the issue, but they don't seem to be faulty. One of them has just ejected on occasion. However it's unclear if this error pertains to media specifically on one of the two drives I am using.


Power cycling was done as well.

All insight appreciated. Sometimes many of us such as myself who typically know to think of these things simply miss a beat here and forget to do the simple things, so all help, checks and reminders are welcome.


Fortunately we have Joe involved since he has a technological perspective deeper than I think the average person would be have about the workings of the tools we use.

May 10, 2023 5:44 PM in response to joema

Joe thanks for this detailed analysis. I couldn't find definitive information on this error code. I did wonder if this was a memory handling problem, but wouldn't know how to diagnose that.


Something I noticed is that when I try to export (share) my timeline, the share window loads relatively quick, but any successive attempts takes a significantly longer time for that share window to present itself. Very strange behavior doing the same operation. This was happening when I tested exporting the first 3,7,10, 60 and so on minutes of the timeline.


Assuming (but not certain) the timeline is processed linearly, the error would come up pretty quick in the export process; especially when I did the 10 minute. Though these were tests after the initial error which seemed like it didn't happen until a high percentage into the export process and therefor the timeline.


Just to be clear, do you want an updated log file only if I get the error again?

May 11, 2023 5:22 PM in response to joema

Joe, I am glad you caught the ExFat format. I was going to mention that in replying to your last post. I recently asked the writer/director why they were ExFat, but she was was surprised too that they were. My intent has been to move this entire project to something like an OWC Thunderbay 4 in a RAID 10 configuration, but running the project from two mounted sparse disk images of the existing two drives. This may sound ridiculous perhaps, but using BRAW Toolbox has been so temperamental with various issues (which by the way may be the fault of FCP/Ventura/M2MAX and not necessarily BRTB) that the idea of moving all of the footage and using BRTB to relink or other issues showing up scares me at this point. I love what it has allowed me to do, but my confidence in things not breaking or being impacted causing more manual time to fix things (literally non-recursive operations) is low. I've tested this potential move using some spare drives I had and it seemed to work. I'd gladly boot up a RAID and mount disk images just to keep working without issue.


Anxious 4 has the most free space and is the drive I was testing exports to in addition to testing those same export tests to my MacBook Pro's SSD. It's also the drive that on occasion will just unmount and remount on its own. All of the ports seem to be OK on my CalDigit TS4 as I have swapped ports for those drives before and got the same behavior. Additionally, the TS4 isn't supplying it power. It has its own. We're trying to get to lock our first round of selected audience notes whereas we'll have a pause and hopefully get this RAID which incidentally will allow me to play the timeline better and catch problems since I can't actually render the timeline without sync, frame jump, or inability to trim issues with the BRTB-created clips. Some parts of the timeline will play just fine, but others are so choppy, even at eighth decode quality, I may not catch problems...all the while being in proxy preferred mode for the RED and footage also on the timeline.


I do hope to get the error again so that I can get the logs. We'll see.

Jan 20, 2024 7:24 AM in response to LocaAlicia

All drives are Mac OS Extended (Journaled)


Original storage with projects and media.

LaCie 6big 50TB with 1.3TB free


Export drive 1 that didn't work.

LaCie 4TB with 0.6TB free (it was a 10TB disk originally but I changed the internal drive to 4TB Ironwolf Pro disk)


Export drive 2 that did work.

LaCie Rugged 4TB with 2.1TB free


Please bear in mind other projects were exporting fine to the export drive 1.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Final Cut Pro error -536870181

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.