APPLE FINAL CUT PRO: Apple Final Cut Pro X FCPX Debates FCP Legacy FCP Tutorials

Re: All the little things that I miss in Fcpx - that become a big deal

COW Forums : Apple Final Cut Pro X Debates

Respond to this post   •   Return to posts index   •   Read entire thread

Joe Marler
Re: All the little things that I miss in Fcpx - that become a big deal
on Feb 9, 2019 at 12:51:09 pm

[Ronny Courtens] "Option to easily relink proxies.

If you want this for remote editing with proxies, you never should have a need for relinking if your workflow is correct."

My doc team uses a proxy-only distributed workflow extensively but it is a hassle. The proxy system is very fragile and clips can easily go off line permanently, which shuts down production. Here's one way it can happen. The current proxy system requires the volume name remain unchanged. In a distributed workflow, the AE preps proxy-only data and ships a portable drive to the lead editor. Then another set of data flows in, proxies generated, and *that* drive is shipped to the editor. But both drives (by necessity) have the same name. If they are both plugged in, Finder shows two drives with the same name. Internally macOS appends a "uniquifier". If the computer is rebooted and the drives come on line in a different sequence the proxies will fail, sometimes permanently.

Internally FCPX is apparently storing within the library the volume name when the proxies were made. Within the SQL tables ZCOLLECTION and ZCOLLECTIONMD this name is associated with each row set corresponding to a proxy file.

If the volume name differs, the proxies will be off line. In some cases renaming the drive to the original name will *not* restore the proxies -- IOW they can become permanently off line. In this case even the "proxy cheat" method of recreating the symlinks by copying in Finder aliases won't fix it.

FCPX proxy management differs starkly from regular media management, which is superb. Regular media management (within a given volume) is so resilient you can shut down FCPX, rename every media file, move each media file to a different collection, go inside the library and manually delete all symlinks, start FCPX and it will find each file and rebuild each symlink to the new location. FCPX apparently stores the inode of each file and uses that as a backup location method to rebuild the symlinks. Unfortunately this doesn't work for proxies.

Inodes are only unique within a volume, so it's understandable why media must be relinked when moving to a different volume name. However there is no relink provided for proxies.

Proxies have inodes like regular files, so it's unclear why that functionality was not provided. Possible reason: When user-specified external storage locations were added in 10.1.2, this also included proxies. Up to that time the assumption was proxies were always inside the library, and the SQL table schema was probably designed around that. IOW the original design did not envision ever having to relink proxies, so it's possible the SQL schema did not store proxy inodes or other info required for a relink. To avoid a schema redesign (which has various implementation and test issues), they just didn't implement inode lookup or relink for proxies.

Posts IndexRead Thread 

Current Message Thread:

© 2019 All Rights Reserved