It may be a race condition where the Inspector needs to change clip metadata that would invalidate transcoded media (RAW / REDRAW, LUT, color space, etc.). Before it does, it calls verifyNoRunningBackgroundTasksForAnchoredObjects to make sure no background tasks (transcoding, analysis, asset‑copy) are touching those assets.
If a background task thread hasn’t quite released the FFSharedLock when that call is made, that's considered a serious code issue, so an assertion fires and crashes FCP. I don't understand why they do that, but that appears to be the case. I might be able to reproduce this, but I won't have time to work on it for several days.
In the meantime, try these workaround steps:
- In FCP>Settings>Playback, disable background render if it is enabled.
- Delete all existing optimized/proxy media.
- Only do manual rendering via selecting clips and CTRL+R.
- Do not adjust any RAW metadata while rendering or any other background task is running. This might apply to making any metadata changes in the Inspector; I'm not sure.
- Do CMD+9 to verify no background tasks are running before adjusting anything in Inspector.
- If problems persist, relaunch FCP before making RAW adjustments. If there are orphaned locks, that might clear them.
- Make sure the FCP library is on a fast local SSD, not a spinning drive or network drive. That may reduce a timing window related to the problem.
- It is conceivable the problem happened sometime between 11.0 and 11.1.1, but I'm not sure. If nothing else works, you could try reverting to 11.0 and see if that helps.
Let me know the results of these tests.
