SOLVED?: Why most of my SD cards cannot be ejected with FCP running.
During the last few years I have asked this question at least twice . . . why can't I eject my SD card while FCP is running?
To be more accurate, I am unable to eject SD cards most of the time but occasionally I can.
The best brains on this forum have been unable to provide a solution but at last I think I have cracked it . . . though, as usual I have been extremely slow at spotting the reason.
Most of my video is shot on an ancient Panasonic SD800 which only shoots AVCHD but I do have other less used cameras that shoot .mov or .mp4.
It seems that my Mac/FCP don't like ejecting AVCHD cards so I put this finding to Gemini who came up with this rather comprehensive reason . . .
"Yes, the AVCHD structure is almost certainly the culprit.
AVCHD uses a complex, highly nested file structure (PRIVATE/AVCHD/BDMV/STREAM...) that macOS and Final Cut Pro treat as a Camera Archive / Virtual Volume rather than a standard folder of isolated video files.
Because of how FCP handles AVCHD media, several distinct factors keep the card locked in background processes:
Why AVCHD Prevents Ejection
- Background Re-wrapping (Demuxing):
- FCP cannot edit native AVCHD .MTS streams directly. When you import them, FCP spawns background daemons (QuickTimePlayerReceiver, AVCHD-Import-Service, or FCPX Media Import) to extract, demux, and re-wrap the .MTS files into QuickTime .mov containers. Even if the visual progress bar in the import window reaches 100%, background background indexing and stream-parsing can hang onto the file handles on the card.
- The "Virtual Camera" Mount Lock:
- When FCP detects an AVCHD directory structure, it mounts the root directory as a virtual camera volume. When you click the Eject icon inside the import window, FCP releases its visual UI link (which is why the files disappear from the import list), but the underlying background process fails to issue the unmount command to the macOS Finder kernel if a file-lock handle is still open.
- Incomplete Copying ("In-Place" vs. "Copy to Library"):
- If FCP is set to "Leave files in place" (or if background transcoding isn't completely finished), FCP retains active read locks on the card. Since AVCHD files generally must be copied into the library, FCP will hold onto the volume until every hidden metadata file in the BDMV structure has been indexed."
That's the gist of the problem. Gemini went on to give some workarounds but honestly they were more complicated than simply shutting down FCP in order to eject.
So there must be other users of AVCHD cameras who are perplexed as to why they can't safely eject their cards but now there appears to be a reason.
Mac mini