-
Relink
When relinking media, is there a way to not have FCPX immediately try to match names as it searches? This is often an incredible waste of time, when you could manually navigate to the desired file more quickly.
– Oliver
Oliver Peters – oliverpeters.com
-
14 Replies
-
I don’t think so. And I agree 100% that it wastes more time than it saves.
—————-
Michael Hancock
Editor -
[Oliver Peters] “When relinking media, is there a way to not have FCPX immediately try to match names as it searches? This is often an incredible waste of time, when you could manually navigate to the desired file more quickly.”
During relink you can navigate to the folder where the file is, click on that and it will only search that one folder. I have seen varying behavior on this in past versions where sometimes it would apparently start searching before you clicked on the target folder. In some past versions this could be very slow. But it currently seems to behave as expected and it seems fast — at least on my machine.
Within a given drive volume, relink is not normally necessary. You can shut down FCPX, rename every media file, move each file to a different location, go inside the library package and delete all the symlinks to the media, start FCPX and it will find all the files and rebuild all symlinks with the new filenames and locations. It is apparently storing the inode or other locator within two SQL tables inside CurrentVersion.fcpevent.
The inode is only unique to a volume so if the name changes or the media is placed on a different drive, then relink is necessary. Relink for media usually works very well. The big problem is there’s no relink for proxies.
-
[Joe Marler] “Within a given drive volume, relink is not normally necessary. You can shut down FCPX, rename every media file, move each file to a different location, go inside the library package and delete all the symlinks to the media, start FCPX and it will find all the files and rebuild all symlinks with the new filenames and locations. It is apparently storing the inode or other locator within two SQL tables inside CurrentVersion.fcpevent.”
I am not seeing this behavior for files stored on our QNAP. When the storage was local I could rename a file at the finder level with FCPX open and it would keep it linked to the file. On our network storage any change in the file name/location throws the file offline and a forced relink is necessary.
—————-
Michael Hancock
Editor -
[Michael Hancock] “I am not seeing this behavior for files stored on our QNAP. “
FCPX does not work well with SMB.
– Oliver
Oliver Peters – oliverpeters.com
-
-
[Bouke Vahl] “Do you have experience with Iscsi with Qnap?”
Me? no.
– Oliver
Oliver Peters – oliverpeters.com
-
In general, or in regards to relinking and file tracking? We haven’t had any problems with it yet, but our read/write speeds are slower on the Macs than our PCs (all over 10G).
—————-
Michael Hancock
Editor -
[Michael Hancock] “In general, or in regards to relinking and file tracking?”
In general. There are specific issues with the types of links it will support. If Ronny Courtens sees this thread he can elaborate. I never run Libraries on QNAP, only source media (in place), so I don’t know the full issue. In general, I don’t find performance to be good at all with FCPX and QNAP. I believe LumaForge recommends NFS if you are working with FCPX.
– Oliver
Oliver Peters – oliverpeters.com
-
Interesting! Hopefully Ronny will chime in with some more info and insights. Bob Z set our system up and it’s been great so far. But we also make extensive use of proxies for a lot of our edits, which might help with overall performance?
—————-
Michael Hancock
Editor -
[Michael Hancock] “But we also make extensive use of proxies for a lot of our edits, which might help with overall performance?”
Yes, I think so. Are the Libraries local or all on QNAP?
– Oliver
Oliver Peters – oliverpeters.com
Reply to this Discussion! Login or Sign Up