Thumbnails blank in large event

I periodically see persistently blank thumbnails on a large event (7000 clips). If I skim across the clip, the thumbnail becomes active, then reverts to blank when the skimmer leaves it. In this state there is no background task indicated, nor does Activity Monitor show appreciable CPU or disk activity.

I have manually deleted the thumbnail media folder in the library and also trashed FCPX preferences -- did not make any difference.

Sequence: I scroll down in the event browser and the thumbnails initially generate and Activity Monitor shows a high I/O rate. But after a while it appears FCPX gets stuck and won't generate any more, no matter how long I wait.

Media is a wide range of mostly H264 content from a variety of cameras. There is no pattern to which media type displays this behavior.

This same behavior was discussed in this thread: www.fcp.co/forum/4-final-cut-pro-x-fcpx/...ser-of-final-cut-pro

System:

2015 iMac 27, 32GB, 4Ghz i7-6700K, 1TB SSD, M395X, 16TB Thunderbay 4
OS X 10.11.15, FCPX 10.2.3

Hey Joe,

Does this only happen in Thumbnail view, or also in List view in the clip browser?

Can you see the thumbnails on your clips in the Timeline?

Thanks.

- Ronny

Ronny, it only happens in thumbnail view, not in list view. Sometimes (but not always) if I switch to list view, mark a range, then switch back to thumbnail view, that one thumbnail is now visible.

I can always see the thumbnails on the timeline, and if I skim the blank browser thumbnail it always shows up in the viewer.

If I scroll up and down in thumbnail view, it will sometimes initiate additional thumbnail generation. The UI thread is apparently sending a message which kicks the thumbnail generation thread to life temporarily.

Apparently the code which manages browser thumbnail generation is trying to optimize by not doing all generation up front but waiting until I scroll down to that portion. Unfortunately there is some other bug where it just gets stuck and no more are generated.

If there was some option to say "go ahead and generate them all" that would be an easy fix. The problem is there's no control over this and it's not working right on large events.

The impact is quite significant since it means I can't easily browse large events. This is not a recent problem, it's been like this a long time.

This confirms what I had expected. It has nothing to do with your Thumbnail Cache. Do you have your Browser on a second display, or is everything on the iMac?

Ronny

It's all on the iMac. I have tested it before with the Browser on a 2nd display and it had the same behavior.

I just checked something. At the 2012 Olympics I had a browser with 8000+ clips on a 2011 iMac with a second display and I did not have these issues. That's why I don't think this problem is related to FCP X, unless it has been introduced with the Library concept. I haven't worked on any Libraries with this amount of clips since then.

But I have some friends who work on a reality show with 5000+ clips now, I will ask around to hear if they have any such experiences. If they don't, it's not related to FCP X and we will have to look at the graphics card. You seem to have no problems with thumbnail displays in List view and on the Timeline. So it could be that your GPU is running out of V-RAM for some reason when it has to display a large number of thumbnails. Too soon to get a definite answer, but I will come back on this.

Question: when you restart the computer and you launch FCP X, do you see any thumbnails in Thumbnail view?

Ronny

Ronny, after further research it appears my Spotlight indexing was turned off on the RAID array. I turned it on and waited for it to rebuild, and now FCPX shows the Browser thumbnails a lot faster, and there are no perpetually blank thumbnails that won't display.

I sometimes hear advice that indexing should be off on media drives, but in this case it clearly had an adverse impact. I don't know if FCPX explicitly calls some Spotlight API or if it indirectly benefits from faster file lookup.

It's still not perfect -- after scrolling down several pages on fresh material it will often initially delay a few sec while thumbnails are built, after that it's persistently fast even after a reboot.

In the worst (infrequent) case after scrolling down several pages, a beach ball appears for 15 sec and Activity Monitor shows an incredible amount of I/O -- over 15,000 per second. I assume that is cached by either the filesystem or SoftRAID. My guess is it's an internal FCPX optimization issue isolated to thumbnail generation and caching on very large events.

They are probably trying to avoid a user-invoked thumbnail generation step such as Lightroom does when you must pick a preview size then wait for it to finish.

Once thumbnails are generated, the presentation stays consistently fast, even if I change the thumbnail height. I'm using single-frame thumbnails but if I increase the duration slider, it has to build those, then it remains fast.

The current behavior on my hardware and data size is perfectly usable. It is a vastly faster way to categorize content than doing it outside FCPX. The old way was based on editing software being slow, transcoding being mandatory, no good way to filter/search media in the editor, and no quick way to scrub multiple clips.

With FCPX I just import everything using "leave files in place". Disk space is cheap and once the initial selects are done that can be consolidated to another library if needed.

Thanks for your help and advice, you nudged me in the right direction and hopefully Spotlight indexing is the only issue.

Joe, this is very useful information and I want to thank you for sharing this.

You are correct that, as a general advice, turning off Spotlight indexing on media drives can improve editing speed. But that's a remainder of times where drives were really slow. Nowadays, as long as you keep your media on a fast external drive, you can safely keep Spotlight indexing on. When you also keep your FCP X Cache folder on that same drive, you must have Spotlight indexing on as this will speed up the thumbnail indexing and rendering. With a project this size, this can indeed make a real difference. I really should have thought about this in the first place.

It's perfectly normal that it can take a few seconds to generate new thumbnails while scrolling through the Browser. I agree they could optimize the thumbnail caching even more. But let's be honest: it works without problems on regular projects and not may people get to deal with this kind of clip count on a regular basis.

I am happy that you have found the solution to this, and I will certainly write it down in my little troubleshooting book in case we get a similar question. I am also pleased to hear that you get a good usable working experience with such a big project.

Happy editing!

Ronny