Media no longer linked on storage drive

[Jeremy Garchow]

I literally drag and drop the entire project – library and all assets to the backup drive.

If everything is truly in the library, you shouldn’t need to drag any assets, only the library.

[Joe Marler]

If he’s literally dragging the library *and* all assets (IOW extra media folders besides library) to another drive, of course relink is required. The drive volume name has changed.

The scenario is confusing because it was originally described as a 100% “all internal” managed library. That is apparently not the case.

As previously explained, any change in drive volume name will cause the external media to go off line. That is regardless of whether the drive is renamed or the media is copied to another drive with a different name. It can be tested by (carefully) renaming the backup drive to the same name as source drive. Typically in that case the links will remain intact.

Obviously it’s not a good procedure to have two drives with the same name due to confusion — that is only a test.

It would be a nice enhancement if FCP allowed “patching in” a different drive volume name for cases like this. However the full pathname (inc’l volume name) is apparently stored separately for each file. If there are 5,000 media files it would require 5,000 logical read/modify/write operations to the SQLite database. If there are referential links to other SQL tables and indexes on those tables it could require vastly more physical IOs than logical IOs. Even if UI existed for that it might not execute any faster than relink.

[Jeremy Garchow]

That’s what I’m getting at Joe. He says it’s in the library, reports that it’s on the library, but somehow the media doesn’t seem to be in the library.

[David Mayer]

Joe,

Your explanation is what I always suspected was the case – just hoped other people had some work around.

For the purposes of opening and editing one project that is on a backup drive, is there any harm in renaming the drive the same name as the original drive? You just have to remember to switch it back later. Would that be enough to fool it?

Maybe the other work around is drag the entire folder back to the original drive?

[Joe Marler]

There is no harm in renaming the backup drive, but the situation can become confusing if two drives with the same name appear in Finder.

There is a trick whereby you can tag one drive in Finder with an emoji character (keeping it visually distinct from a non-tagged drive with the same name), and this does not modify the drive name from the standpoint of FCP. To use emoji tags do CMD+I on the drive, place the cursor after the drive name and do CMD+CTRL+spacebar, and append an emoji character to the drive name. I haven’t tested it extensively but it seems to work, at least on Catalina 10.15.7.

If the media itself is identical and only the library (which contains the edits) differs, it doesn’t matter which data set the library connects to. The library on the backup drive could connect to the media files on the main drive. It’s a good idea to rename the library itself, e.g, MyLibrary vs MyLibraryBackup, and maintain awareness within FCP of the library name you are using. Otherwise you can end up doing work in the wrong library.

An advantage of using a “lean library” (with cache and media external) is backup. That way the library only contains the edits, is very small and can be quickly duplicated and copied in Finder. This also makes it easier to keep the library on an SSD. The library itself requires many small random IOs which can conflict with the large sequential IOs for media. The cache is also important to keep on an SSD, but it doesn’t require backup.

Or you can just relink. Normally relink isn’t that slow but if both library and media are on a single HDD and if many files are involved, it can be take a while.

[David Mayer]

makes sense

love the emoji idea

thanks