Every Edit Yields Beach Ball - Maybe Validation Task

[tangierc]

Folks, I am having some strange behavior from FCP 10.7.1 on an M2 Max MacBook Pro with Sonoma. The library and cache files are on my computer. The media is on my RAID. Every time I make an edit or undo that edit, I am stuck waiting for FCP to complete and action and hear my RAID to work hard.

1. All I can barely see (before it disappears) from the task monitor is that FCP is doing some sort of Validation, but usually it says idle and the parent task monitor wheel spins for a bit.
2. After an edit, FCP hangs for a bit with the spinning beach ball until it stops and I can move on to any further edits.
3. Undoing an edit yields the same result
4. I did not have this issue recently on the same project, same media, same RAID (OWC Thunderbay 4 in RAID 10 connected via Thunderbolt 3).
5. This is only happens in Proxy only and Proxy Preferred playback modes, but does not seem to happen in Original / Optimized playback mode. My proxies are in ProRes not H.264.
6. Deleting clips or moving clips does not cause this to happen.
7. Timeline is 4K UHD @23.98 fps with three professionally mixed audio roles (for D,M&E) and a few Motion VFX and Final Cut Bro Plugins

Any thoughts folks? Proxy modes typically work more smoothly so this is odd behavior.

[latenitefilms]

Have you tried moving your proxies to your internal drive?

[tangierc]

Proxies working great on the internal SSD. RAID seems to be healthy though too.

[joema4]

If it works OK with proxies on the internal SSD, that implies I/O, but I don't understand why. The normal I/O profile for media reads (inc'l proxies) is large sequential I/Os. However there is a secondary I/O profile when rebuilding thumbnails, esp. if the browser is in filmstrip mode and you have thousands of clips.

There has long been a quirk with "in place" bare AVCHD files (e.g, MTS, M2TS) whereby a few of those can "poison" the I/O performance of an entire library. The symptom is abnormally chattering mechanical drives, and sluggish scrolling in the event browser. Do you have any of those in that library?

It is, unfortunately, difficult to characterize the I/O performance on MacOS because there's no tool like Windows Perfmon that displays the disk queue depth. Years ago the DTrace utility "iopending" did that but it no longer works, even with SIP disabled. It is possible to use XCode Instruments to get good I/O latency data, but it's complex.

Also I'm not sure it's needed in this case. You don't need Instruments to confirm your I/O bottleneck -- you can hear it. The question is what is it doing and why?

It is fairly easy to use terminal's fs_usage command to monitor all the file I/O done by FCP during a slow period, then sift through it using grep or BBEdit. Syntax: sudo fs_usage -w -f filesys 'Final Cut Pro' > ~/Documents/fs_usage1.txt

Columns in output:
timestamp, I/O call, file descriptor of the form F=x, disk block # of the form D=0x (hexadecimal),
transfer size in bytes of the form B=0x (hexidecimal), file offset of the form 0=0x (hexidecimal),
pathname to file, time elapsed of I/O call in seconds (e.g, 0.000353), (if followed by a 'W' it
means the process was scheduled out during the call), process name, and thread ID.