Choppy Timeline Editing - Getting Back to Fluidity?

Joe, I should mention (again?) that I noticed my CPU cores maxxed out when horizontal scrolling some versions of Tangier's timeline. It's like FCP was trying to redraw/cache some aspects of the timeline even though the clip appearance was set to labels only. After changing clip appearance "mode" and maybe the clip heights, then going back to minimums of both, the CPU pegging behavior disappeared. This may be useful info to pass along to Apple. I wish I could consistently get it to repeat. I wonder if it may be related to Tangier's mention of things improving (performance-wise) after "touching" certain objects in the FCP interface...

P.S. - In some cases, even with clip appearance set to "labels only" and clip height to minimum, during those horizontal scrolling instances I could see thin red "lines" "redrawing/updating" as I scrolled or paused scrolling. Those "lines" appear to have been the "missing proxy" overlays, as those overlays took some time to redraw/refresh when the clip height was more than minimum and the appearance set so that the video thumbnail was visible. And, after a bit of time, those red "lines" would disappear. Strange... Is it possible that besides FCP "hanging" or being slow for certain UI operations that there could be an issue with the GPU drivers contributing to things?

Dave, never a bother. You're using your time to help and I appreciate that sincerely.
The drive is an OWC Gemini in RAID 1 with a total of 18 TB in that config. 36TB in RAID 0
The FCP library (unmanaged), cache folder, and proxy media are all contained in one top level folder on the drive.
The backups have been moved off the Gemini.

I'll move the cache files off of the Gemini. It has a built in SD card slot which would be great to use, but  an SDXC card wouldn't be as speedy as my G-Tech portable SSD.

tangierc wrote:

I'll move the cache files off of the Gemini. It has a built in SD card slot which would be great to use, but an SDXC card wouldn't be as speedy as my G-Tech portable SSD.

Just to be clear (and I'm sorry if this is repetitive or if I have misunderstood), you want the library itself and cache on an SSD. The proxies, etc. can stay on the mechanical RAID. If that hasn't been done, please re-evaluate the performance in that configuration and let us know. 

There will still be cases where it must re-read the media files (albeit proxies in this case) to rebuild the thumbnails. I'd prefer an option similar to LightRoom where you can just tell it to generate preview or thumbnail images at a given resolution ahead of time. You then pay that penalty once. However with FCP filmstrip mode that might not be feasible. It's not simply a thumbnail per clip but depending on the filmstrip size it could be many, which the user may dynamically change by stretching out the filmstrip.

There was formerly a major I/O issue with AVCHD files imported with "leave files in place" that caused tremendous I/O when scrolling down the event browser in filmstrip mode. I haven't seen that in a long time. It was formerly easy to measure that using the command-line DTrace utilities but many of those no longer work, plus they require running with System Integrity Protection disabled, which on an Apple Silicon machine might require startup security changes made while in Recovery Mode. If I have time I'll test that.

However there is no question there's a timeline compute problem separate from any I/O issue. I'll be examining that more today.

To review possible near-term mitigation steps:

- Ensure cache and library on on a separate SSD

- To the extent possible and reasonable, continue work of reducing markers, compound clips, etc.

- After the changes thus far, re-check if setting clip appearance to "labels only" (CTRL+OPT+6) helps much. You can switch between the other clip appearance modes with CTRL+OPT+5, 4, 3, etc. I realize using "labels only" may not suit you, this is just looking for a temporary workaround or a clue about the problem behavior.

- You do not have an excessive number of projects or extents. However if it's not burdensome, further reducing the number of projects might help. Apparently that issue is the product of project complexity times number of those projects, snapshots or duplicates. I'm not sure of the exact scaling factor.

Thanks Joe. I did have my library on the Gemini. I'll move it to the SSD with the cache. I am already deleting unneeded events and projects.  I'll check the performance later today. FCP was none too happy about deleting events that had the projects I used to setup this edit and test.  Too often deleting an event that wasn't one of my footage "Day x" events caused FCP to beachball and the drive was mostly silent; almost no drive activity. I would often have to force quit after deleting an event, because it would not let me do a second one. Of course I did give FCP plenty of time to complete the action...going to do something else for about 20 minutes or so and coming back to see if the deletion was complete, but usually it wasn't I've gotten it all squared away now though. I moved the library to another machine (M1 iMac), media offline of course, and deleted the problem events and merged two. It hung for a brief moment, but it worked.

I'll let you know later how the testing goes.

Thanks

tangierc wrote:

...FCP was none too happy about deleting events that had the projects I used to setup this edit and test. Too often deleting an event that wasn't one of my footage "Day x" events caused FCP to beachball and the drive was mostly silent; almost no drive activity. I would often have to force quit after deleting an event, because it would not let me do a second one. Of course I did give FCP plenty of time to complete the action...

That should never happen and indicates some kind of underlying problem -- FCP, library corruption, plugin, system layer, etc. There are ways to troubleshoot that but unless it persistently reoccurs it's probably not worthwhile. Keep us informed if that starts happening again after moving the library and cleaning up.

Do you have the Chrome browser installed? For a long time there was a problem with that conflicting with the MacOS Video Toolbox framework, which would case periodic FCP hangs and crashes. However I thought that was fixed.

It seems that it is a known issue that having over about 1000 to-do markers causes FCP to slow down significantly. Larry Jordan mentioned this in his webinar today, as well. I don't know if anyone has reported this bug to Apple. It might be good to include in your report to Apple, Joe. Thanks!

tangierc wrote:

. . .

The way FCP delays loading certain data has had a significant impact on large or complex projects performance will doing a Reveal in Browser or searching for a clip in the browser. I've even tried paying close attention to how large my font library since I wasn't certain what FCP loads into memory when launching a library.

. . . 

Tangier, one of the reasons it is suggested to trash and re-download the FCP application itself is because many fonts are stored within the application's bundle (~71 for FCP, ~66 for Motion). Any testing or repairing of fonts in Font Book won't check the embedded fonts. This is not to suggest any of the current issue(s) involves fonts, it's just a tip, of sorts...

Two Copies of the media-one on an OWC Gemini and another on a LaCie Rugged Mobile RAID
Common Across All Below Tests

1. FCP (unmanaged) library, cache, and backup on G-Tech USB 3.1 (USB-C) SSD
2. Library size = 443 MB
3. Event count = 23
4. Timeline TRT = 01:37:18:00
5. Timeline settings: 4K UHD @ 23.98, Stereo audio
6. Project count = 2
7. Compound clip count = 87
8. Marker count = 21
9. Attached storyline count = 432
10. Media being used: ProRes Proxy, .WAV audio files, mp3 and mp4 originals

Deleting or merging events on the Mac Pro was terribly slow or problematic often requireing a force Quit. Tested same operation on 2016 MacBook Pro (another Intel and it took about 1.5 minutes to merge two events with causing a force quit. 2013 Mac Pro 
Media Storage: LaCie 4TB Rugged Raid Thunderbolt 2 drive

1. Library launch times improved.
2. Project launch time improved.
3. Horizontal and vertical scrolling mostly smooth. Slightly faster when in label view than when drawing frames and waveforms. 
4. Frame and waveform timeline view scrolling greatly improved.
5. Scrolling vertically to view event list beachballs briefly just the first time.
6. Clip, clip head and tail movement and manipulation still choppy responsiveness. Marginally better in label view. Editing possible, but would be slow
7. Shift+Z (show entire timeline) , zoom in and zoom out via keyboard lags (brief beachball), but improved.
8. Reveal in browser improved. Searching in browser invokes loading project screen, but time is very improved.

2013 Mac Pro 
Media Storage:OWC Gemini via Thunderbolt 2 (Thunderbolt 3 to Thunderbolt 2 adapter) RAID 1

1. Library launch times improved.
2. Project launch time improved.
3. Horizontal and vertical scrolling mostly smooth. Slightly faster when in label view than when drawing frames and waveforms. 
4. Frame and waveform timeline view scrolling greatly improved.
5. Scrolling vertically to view event list beachballs briefly just the first time.
6. Clip, clip head and tail movement and manipulation still choppy responsiveness. Marginally better in label view. Editing possible, but would be slow
7. Shift+Z (show entire timeline) , zoom in and zoom out via keyboard lags (brief beachball), but improved.
8. Reveal in browser improved. Searching in browser invokes loading project screen, but time is very improved.

M1 Pro MacBook Pro
Media Storage:OWC Gemini via Thunderbolt 3,  RAID 1

1. Library launch times vastly improved.
2. Project launch time vastly improved.
3. Horizontal and vertical scrolling very fluid. Faster when in label view than when drawing frames and waveforms. 
4. Frame and Waveform timeline view scrolling greatly improved.
5. Scrolling vertically to view event list very fluid.
6. Clip, clip head and tail movement and manipulation a little laggy, but workable for editing.
7. Shift+Z (show entire timeline) , zoom in and zoom out via keyboard lags, but useable
8. Reveal in browser and searching for clip in the browser happens in about 2 seconds at the most. Reveal in browser drastically improved
9. Anomaly while editing: A clip went offline on the timeline. Does not have the yield missing file icon on the clip in the browser, but does present as a missing file in the viewer. Reveal in finder shows that the file is linked to it’s proxy correctly.

Also tested M1 Pro MacBook Pro and M1 24” iMac using LaCie 4TB Rugged Raid via Thunderbolt 2 drive. Results were similar to above with OWC Gemini. Except for the anomaly which already happened prior.

Hey people,I also have a timeline which is sooo laggy, it's driving me crazy. I am preparing a 2 h documentary for color grading handoff at the moment. I have to add a timecode and add all kind of information about effects. I have to drag clips to different "Lanes". But drag and drop / duplication of a bunch of clips takes minutes! Here an Example where the drag and drop takes over 2 minutes, CPU goes to 100% and it seams almost that FCPX crashed:


When I delete my reference video which is a 2h clip, the lag is gone!
But I really need that clip to check if everything is ok.
I noticed, that as soon as I have a clip (activated or deaktivated) or even an empty (filled with gap) connected storyline that reaches over the whole 2h timeline, the lag will start. Maybe this is the part of the bug that others are describing here in the post.

Here is the same procedure without the connected reference clip. Not 100% smooth like on a 5 min timeline but only a second instead of 2 min.

danielfcp wrote:

Hey people,I also have a timeline which is sooo laggy, it's driving me crazy....

Can you please send me a project XML of the slow timeline. It need not have any data, just the XML. You can place it on this write-only DropBox link:  www.dropbox.com/request/w5Tb4uisD75ou49ilWYt