[Joe Marler]

[Oliver Peters] “…on this batch of revisions, when you try to follow this process, you can never stop the “looking for matching filenames.” So at each step you get a spinning beach ball for a while until it to a point where it lets you go to the next folder.”

I just noticed there was a fix in 10.4.1 which says: “Relink Files button highlights after selection, allowing you to press Enter to commit the command”.

While that fix is vaguely worded, the problem I formerly saw might be described that way. IOW it would not wait to initiate the relink search until you pressed Enter – it would immediately start. This prevented isolating the relink search scope. However I think more was wrong than that, but fixes in release notes are not comprehensive.

I saw this problem frequently before 10.4, but I don’t recollect seeing it since then, at least on locally-attached storage.

[Joe Marler]

[Jeremy Garchow] “You can select the new drive and hit “choose”

You don’t have to wait for anything else.”

Oliver was taking about an intermittent bug whereby you *can’t* hit “choose”. The relink UI yanks control from you and goes to a beach ball. It is apparently enumerating something in the background for several minutes. Then it finally finishes and you can select the folder and the rest of the relink process is normal. On very large datasets I’ve seen this phase take 10-15 min. This is on various local Thunderbolt 2 arrays, not just a NAS.

I used to see this frequently when relinking very large datasets, but not recently. Hypothetically it could be the difference between a brute-force sequential search for metadata in thousands of files vs an indexed Spotlight lookup.

Oliver is on a NAS and Spotlight indexes don’t always work correctly there, but it’s just speculation it’s even using Spotlight. It could be something else. But it’s a bug, not lack of a feature. It usually works OK but in some cases the relink performance falls off a cliff.

[Joe Marler]

[Oliver Peters] “ometimes that does go fast. But on this batch of revisions, when you try to follow this process, you can never stop the “looking for matching filenames.” So at each step you get a spinning beach ball for a while until it to a point where it lets you go to the next folder.”

I have definitely seen this behavior, just not in a while. It is abnormal and very slow. It sometimes yanks control from the user before you can even point the UI to a folder. There is no progress bar, but a spinning beach ball for a long time, which itself indicates poor programming or a malfunctioning system layer.

Was the media on shared storage? Was the media indexed for Spotlight searching? If it’s using Spotlight lookups to expedite the searches, some aspects of this may not work properly on a NAS. In my testing, filename searches work but some metadata searches are unreliable on a NAS. FCPX would have to read metadata to determine relink compatibility.

If it’s on local storage it would be interesting to rebuild Spotlight indexes on that and see if it makes a difference. https://support.apple.com/en-us/HT201716

[Joe Marler]

[David Cherniack] “AFAIK it had all to do with playback…which was why it was called a playback engine. It worked in the first 64 bit build of PrPro as I recall. GPU acceleration worked with some effects, not with the actual decode of the codecs during playback…”

That was also my recollection. MPE was a catch-all term for numerous performance enhancements to the playback engine, including improved multi-threading, 64-bits, and GPU-accelerated effects. Initially only some effects were GPU-accelerated but the entire playback engine felt fast. Adobe obviously had done a lot of profiling work to optimize decode-oriented code paths.

The Premiere intro video still on Adobe’s web site today describes it as allowing “editors to work with 4k and beyond, without time-consuming transcoding”, and “never needing to render until your work is complete”: https://helpx.adobe.com/premiere-pro/how-to/what-is-premiere-pro-cc.html?set=premiere-pro–get-started–overview

Back in the DV and 1080p H264 days, CS5/CS6 did seem very fast on period Windows machines. The ability to edit compressed native camera formats with good performance and without transcoding was impressive – it wasn’t just an advertising slogan.

That raises the question, over time did the other NLEs get disproportionately faster on newer hardware generations or was Premiere not that fast back then but the other NLEs were even slower?

I recollect CS5 as seeming very fast. However when I recently inherited a cross-NLE project and had to concurrently run Resolve 16, Premiere 14 and FCPX 10.4.8 on my 10-core Vega 64 iMac Pro, FCPX felt super fast, Resolve felt nearly that fast, and Premiere seemed very laggy and sluggish.

I think some of it is just aesthetic – the FCPX skimmer is hyper-responsive and Resolve 16 is similar. But that doesn’t necessarily make you edit faster. There’s a difference between feeling fast vs producing more completed work fast.

[Joe Marler]

[Oliver Peters] “The FCPX Library linking is based on the shared storage locations at the office. I have had to move assets from multiple drives onto a single RAID, so paths are completely a mess. Relinking in FCPX is nearly impossible. “

Oliver, could you clarify this? While there are some major FCPX re-link issues, in general the above case works for me – provided the filenames are unique. IOW I can combine multiple media trees from a NAS to a directly-attached RAID, change all the paths, and FCPX File>Relink Files will rapidly scan the entire volume and relink all the files.

[Joe Marler]

[Oliver Peters] “Catalina, what are your general experiences thus far? I’ve seen a number of issues posted lately, like frequent reboots.

If you’ve had bad experiences, are these fresh installs on new machines or migrations/updates from earlier OS versions?”

I have seen this problem on a few Catalina machines, but not all of them:

In the FCPX inspector if I do Storage Locations>Modify Settings, then for media or cache pick a location and create a new folder, the FCPX process will hang on that dialog and require force quit.

Only known workaround is create the new folder first in Finder, then do CMD+I and under Sharing and Permissions, grant read & write to Everyone. After that, designating that existing folder in FCPX for media or cache works. Happens on all disk locations, inc’l Desktop, Documents, Movies, internal drive, external drive, etc. All drives are locally-attached, either Thunderbolt or USB-C, formatted APFS for internal and HFS+ for external. As a test I de-installed Paragon NTFS and SoftRAID but it made no difference.

It is apparently a Catalina-specific permissions problem. I ran Disk Utility First Aid and also granted FCPX full disk access in System Preferences>Security & Privacy, but it made no difference. Also reset FCPX prefs, then totally removed FCPX and re-installed – no difference. The workaround is simple, and it doesn’t happen on every machine, but I never saw that on Mojave.

[Joe Marler]

[Jeremy Garchow] “Indeed it does. It’s the only one that works”

You are correct, the auto-relink based on inode is very slick but it only works within a single disk volume.

There are some cases where manual relink to externally-generated or transcoded files fails. It works with Sony XAVC-S .mp4 files, RED camera-generated proxies and others. It fails with MXF files and some old AVI DVC material I tested – even IF using proxies generated by FCPX itself and copied externally.

The reason seems to be a difference in audio metadata. Either the audio data in the original files is not written correctly or FCPX is simply mis-handling the audio in the transcoded file, or mis-handling the check itself. In some cases it inappropriately fails. Using Invisor’s side-by-side comparison I can see some parameters of the audio are different between the original file and the proxy generated by FCPX – just blank in some fields.

In my MXF and AVI test files the audio plays OK in both original and transcoded files but during the relink FCPX complains “Incompatible file – the original file had audio, but the new file doesn’t”. The transcoded file has audio and it plays OK.

That’s not a feature deficiency, it’s just a bug. It should work.

I’ve also seen cases where media imported within an FCPX managed library will not allow relink to the original offloaded file, except one at a time. In this case it’s not re-wrapped, the file was just copied to the library and renamed by FCPX during import.

Unfortunately the media file header is not composed of neat alphanumeric fields that you could easily tweak with a hex editor but includes complex, conditionally-encoded binary values: https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-75770

There is another half-implemented undocumented feature that indicates Apple has worked on this but not to completion: You can move media files to a new drive then create Finder aliases via OPT+CMD drag and copy those to the symlink folder within the library, and usually FCPX will re-read those and generate updated symlinks. But it doesn’t always work.

Everybody complaining about this is correct — this entire area needs a lot of work. Unfortunately both Apple and much of the FCPX community places a lot of emphasis on visible user-facing features, but there are poorly implemented system-facing issues that need major work.

[Joe Marler]

[Jeremy Garchow] “Try it. Take an mxf file, make any file format you want with matching audio, and try to relink it, automatically. It won’t happen.”

I just imported several MXF files using “leave files in place”, shut down FCPX, renamed each file, moved each file to a new subfolder, then deleted the symlinks in the library which pointed to those files, and upon re-launching FCPX it automatically relinked them instantly and re-created the symlinks to the new locations and filenames.

[Joe Marler]

[Jeremy Garchow] “All I want for quarantine is better format relinking in fcpx.”

Relinking in FCPX is both superb and terrible. Relink of regular media files on a single drive volume is superb – in fact it’s fully automatic.

You could have 1,000 “in place” media files scattered across a huge RAID array, shut down FCPX, rename each file, move each file to a different location on that drive, then inside the library *delete* the symlinks to each of those files, then upon re-launch FCPX will automatically relink all the files and rebuild the symlinks. This is because the library not only stores the path but also the inode of each media file and uses that as a fall-back locator. Is there any other NLE that does this?

By contrast relink of proxies is terrible – in fact it does not exist.

In between those two extremes are other cases where FCPX relink doesn’t work that well. E.g, if the media files are renamed after import *and* they are moved to another drive. Since inodes are only unique within a volume, it can’t use that method. There are cases where relink requires doing one file at a time.

Obviously one answer is “just don’t ever rename the files” after import, but there are reasons why this is done.

How does Premiere handle this? Say you commit a lot of work to a project, then transfer the data set to a NAS and as part of that move the media files are renamed. Can it batch relink the entire data set? When I formerly used Premiere it would not do that.

[Joe Marler]

[Brian Thomas] “that still only provided a range in the main storyline/Timeline, not in an independent audio track attached below the storyline/Timeline.”

If clip skimming is enabled, you can use R mode and draw a range on a detached audio clip, then copy and paste that elsewhere via Edit>Paste as Connected Clip. This works for both primary and secondary storylines, and for both primary and connected clips.

If you are *inside* a multi-cam clip, then it won’t show the clip skimmer on the monitoring angle; you’d have to select a different monitoring angle with the little TV icon at left of each angle, then skim the non-monitoring angle. Inside an MC clip you can select and copy a range but there is no option to paste as connected clip. But you can paste it to the monitoring angle then move it using position mode (P key).

You can verify clip skimming is working if the thin red skimmer playhead is only the height of a single clip. If the thin red line is the full height of the timeline that is the regular skimmer not the clip skimmer.