SuperAPI AI Directory

lov-migrate-camera-media

Office & productivity

View repository

Updated 10-16 00:01

About this skill

Camera Footage Migration

Version: 0.1.0. Execute in the order: "check device → check link → full-card copy → full verification → spot-check footage → authorized card wipe." Use the source path, destination path, risk choices, and authorization from the existing session; do not repeatedly ask about matters already confirmed.

Triggers

Activate when

  • Offload footage from a camera or memory card to an SSD and verify whether it is complete.
  • Troubleshoot slow Sony transfers, resume after a cable swap, or the card-wiping process after backup completion.

Do not activate when

  • Only video editing, subtitles, photo color grading, or corrupted footage recovery is needed; this Skill is not responsible for those outcomes.
  • When the device is not mounted as a macOS file system volume, resolve the connection method first; do not directly run the migration script.

First Define Outcomes and Authorization

  • When answering "how to do it" or "can it be done," explain and perform read-only checks first. An explicit migration request executes copying and verification; moving across drives also requires copying and offers no speed advantage.
  • By default, keep the source card. Only enter the card-wiping step when the context has explicitly authorized deleting this card; a single technical feasibility question alone is not sufficient to substitute for deletion authorization. If explicit authorization already exists, no further confirmation is needed.
  • Treat 3-2-1, multiple independent backups, and unrecovered footage as suggestions and status explanations. Once the user understands and accepts the current backup arrangement, do not repeatedly block authorized card wiping with the same suggestion.
  • Do not inherit the real-case authorization of this Skill. Confirm the actual target each time; do not automatically format, erase an entire drive, delete other cards, or clean up backups.

1. Read-Only Check and Speed Test

First read the identity, format, and available space of the source volume and destination volume. Archive each card into an independent directory, and place the manifest and logs in an adjacent report directory, both outside the source card.

python3 scripts/camera_media.py inspect --source '/Volumes/CAMERA_CARD' --usb
diskutil info -plist '/Volumes/ARCHIVE_SSD'

Obtain the Volume UUID from actual output; do not treat variable disk4 and similar device numbers as permanent identity. Count the logical bytes of all files, including hidden files, empty directories, XML, databases, proxy files, and RSV; count main photos and video thumbnails separately. Do not read or archive software installation volumes additionally mounted by the camera, such as PMHOME。

Verify the negotiated rate before mass copying. If the actual read speed is about 1 MB/s, first check UsbLinkSpeed; the theoretical upper limit of 12 Mb/s is only 1.5 MB/s. First rule out cable, interface, and card reader limitations; do not directly estimate using SSD advertised speeds. Before requesting a cable swap, safely stop the current process and confirm it has exited, preserving partial files; after reconnecting, recheck the UUID and manifest.

For details on Sony FX3A and macOS/exFAT, read as needed Platform and Speed. For other camera capabilities, consult their official documentation; do not generalize from the FX3A.

2. Copy and Full Verification

Use Python 3.9+; the offload script requires the xattr module. First use python3 -c 'import xattr' to check the available runtime environment and reuse an already installed environment. Resolve missing dependencies first; do not start a hundreds-of-GB copy only to discover the interface is unavailable.

The following paths and UUIDs are placeholder examples; replace them with the actual values just read. The destination card directory and report directory should not yet exist; when resuming, reuse the same set of parameters.

caffeinate -i -m python3 scripts/camera_media.py transfer \
  --source '/Volumes/CAMERA_CARD' \
  --destination '/Volumes/ARCHIVE_SSD/活动/原始素材/相机-卡01' \
  --report '/Volumes/ARCHIVE_SSD/活动/转存校验/相机-卡01' \
  --source-uuid 'SOURCE_UUID' --destination-uuid 'DESTINATION_UUID'

Have the script read the card sequentially, write to the SSD in parallel, and compute SHA-256, using limited memory buffering. It preserves .partial, when resuming, compare the copied prefix byte by byte and recompute the source hash state; do not blindly append. Preserve filenames, directories, timestamps, and extended attributes; do not copy the camera's protection flag to the working copy.

After copying is complete, reopen the target file and read it back to compute hashes, verifying all source file paths, sizes, hashes, and directory sets. Save manifest.json、checksums.sha256、status.json. A successful verification status is verified; on encountering an anomaly, retain the error and intermediate artifacts, and do not report completion.

verify The subcommand accepts the same set of five path/identity parameters and can re-verify while the source card still exists. After the card has been cleared, do not run verification that depends on a source snapshot; use the archive manifest to run from the target card directory shasum -a 256 -c '/绝对路径/checksums.sha256' to check the backup itself.

3. Handling disconnections and source manifest changes

Use inspect --source ... --compare '/报告目录/manifest.json' to check for added, missing, and changed files. On failure, do not delete the lock, turn off verification, or directly overwrite the old manifest.

  • Source unchanged: resume using the same parameters; for existing complete files verify first, and for partial files check the prefix first.
  • Source changed: retain the old manifest, old report, and incomplete copies, and output the differences. Ask only questions that affect the result, such as "Were these clips transferred separately?" Back up the current content using a new card directory and report directory, and do not describe the smaller new snapshot as if the entire original card had been fully backed up.
  • User provides another destination: check the specific files and XML, original sizes, and spot-check playability. If old source hashes exist, compare hashes; if not, you can only report "count/size consistent, spot checks passed" and cannot claim byte-for-byte consistency. Record the confirmed destination and verification scope.

Do not infer from changes in a new snapshot that data has been corrupted or deleted by the user. Do not carry out data recovery without authorization.

4. Material spot checks and delivery

If Pillow, ffmpeg, and ffprobe are present in the installed environment, run:

python3 scripts/check_media.py --report '/Volumes/ARCHIVE_SSD/活动/转存校验/相机-卡01'

Select only real files from the manifest, and avoid treating macOS ._*.MP4、._*.JPG as material. Decode all MPO frames of photos; for each supported video, check the first, middle, and last frames and a segment of the audio track. Record unsupported formats and RSV files for which recovery was not attempted. Sample decoding is not full-video frame-by-frame verification, nor is it manual audio-visual review; matching hashes do not prove that the source recording was originally playable.

Wait for long tasks according to the host mechanism, providing meaningful progress at least every 60 seconds. Report copy speed, verification speed, and completion status separately. Finally, read back the manifest and results, and briefly deliver: paths, file count, byte count, elapsed time, verification scope, destination of anomalies, RSV status, whether the source card is retained, and whether a second backup exists. Copy the user-visible report to the delivery directory as required by the host.

5. Authorized card clearing

First read card-clearing rules. Prefer recommending in-camera formatting. When the user has explicitly chosen computer-side clearing and has accepted the backup arrangement, computer-side cleanup may be performed; state the manufacturer's recommendation once, and do not treat it as a permission restriction that cannot be carried out.

Use cleanup and the same five parameters as for transfer to first generate a read-only plan; by default it will not delete. Confirm the card UUID, source files, verified copies, protected files, and bytes proposed for release in the plan.

After authorization is explicit and the plan is within scope, append --apply --confirm-source-uuid 'SOURCE_UUID' to execute. This parameter is only a guard against accidental triggering and does not provide user authorization. The script deletes only files in the original manifest that are still unchanged and whose backups match, skips protected files, does not erase uchg, does not sudo, and does not change partitions or the file system.

After clearing, read cleanup.json, remaining files and actual available space, update the source card status in the report.cleared_with_retained_files is not equal to a completely empty card; explain the retained content and size item by item. The camera may still require in-camera formatting to initialize the database.

Maintenance

After script changes, run PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -v. Tests use only temporary directories and injected volume identities; it is forbidden to test deletion logic with a real card. For findings and evidence boundaries in real-world use, see Case。