[Pawel Kasprzak]

It’s fibre channel. Looking at what you’ve posted here, a SAN upgrade wouldn’t probably solve this in my case. It’s some network problem on FCP’s side perhaps.

Thumbnail and cache files tended to cause problems with “classic” FCP as well. I usually work in a networked group environment so I always need all media, project files etc. and even cache files stored on some network drive – and this included audio waveform cache as well. The thing with these files has always been that there’s a lot of them, they’re all stored flat in the same folder and they’re very small. A SAN folder defined as waveform cache destination – when stuffed with some considerable number of files – would make the system very slow, so I used to have another network volume to handle that. I suspected we might now face a problem of the same kind – our storage drives are not optimized for such small files (each of them stores data for about 1000 frames only). But I tried storing these thumbs locally and this didn’t help. Or I’m doing something wrong – quite likely as this is my first attempt to use FCP X. Wonder if there’s any workaround or should we wait for another fix to follow…

BTW – you have mentioned using ProRes multicam over a network under FCP 7. Doing the same I would have other issues. Our editors exchange their projects a lot, they also use “archive projects” with preedited sequences etc. What they do all the time is they copy and paste from one sequence to another. And this would somehow corrupt the project files. The system would hang (a spinning cursor wheel) the console log would show memory allocation error. A quick help was to launch Compressor – strange remedy, but this would flush client station’s RAM, which would instantly get the system back to operation. Alas the project files would seemingly get hit even worse afterwords. What would make them perform better for some time was to export an XML from them and import it to a new project. Then you could work for some time until another copy and paste operation hurt you again. What was really weird was that this would happen with ProRes files only – DVCProHD and even XDCAM didn’t cause that. ProRes Proxy turned out to be even worse than ProRes SQ, which suggested that ProRes compression must be very RAM and CPU consuming – the more compressed files, the worse for your memory. So perhaps it’s ProRes that kills us now. No idea.

[Pawel Kasprzak]

Hi, I have pretty much the same with an xSAN volume. A 7-angle ProRes 422 multiclip would play back ok if the files were stored locally, but I had constant dropped frames with the same media from a SAN drive. No matter if the thumbnails were stored locally or on a SAN drive. By the way storing thumbnails there seems a crazy idea as thumbnails are tiny and there’re hundreds of thousands of them – which is not exactly what SAN volumes are optimized for. Anyway – 4-angle multiclip plays back fine over a network. With 7-angles activity monitor shows jumps in CPU usage (from under 100 to above 500% in my case). Just as Michael describes – FCP 7.0.3 handles the same media well.

I suspected I needed an update to my SAN system. My current SAN version is 2.2 and OS was Snow Leopard (dropped frames), which I’ve just upgraded to Lion leaving SAN at 2.2 (we have a large production going on so I’m not really into any major changes) – still dropped frames. According to what Michael says here the SAN upgrade to 2.3 will not solve the problem.

Does anybody know what are the thumbnails that FCPX generates on multiclip creation BTW? Filmstrip thumbs for each of the clips are already there. Perhaps FCPX uses a different set when it comes to displaying angles in a multicam window? Anyway – this I made sure – dropped frames don’t seem to depend on where the thumbnails are stored.

[Pawel Kasprzak]

Hi, I have pretty much the same with an xSAN volume. A 7-angle ProRes 422 multiclip would play back ok if the files were stored locally, but I had constant dropped frames with the same media from a SAN drive. No matter if the thumbnails were stored locally or on a SAN drive. By the way storing thumbnails there seems a crazy idea as thumbnails are tiny and there’re hundreds of thousands of them – which is not exactly what SAN volumes are optimized for. Anyway – 4-angle multiclip plays back fine over a network. With 7-angles activity monitor shows jumps in CPU usage (from under 100 to above 500% in my case). Just as Michael describes – FCP 7.0.3 handles the same media well.

I suspected I needed an update to my SAN system. My current SAN version is 2.2 and OS was Snow Leopard (dropped frames), which I’ve just upgraded to Lion leaving SAN at 2.2 (we have a large production going on so I’m not really into any major changes) – still dropped frames. According to what Michael says here the SAN upgrade to 2.3 will not solve the problem.

Does anybody know what are the thumbnails that FCPX generates on multiclip creation BTW? Filmstrip thumbs for each of the clips are already there. Perhaps FCPX uses a different set when it comes to displaying angles in a multicam window? Anyway – this I made sure – dropped frames don’t seem to depend on where the thumbnails are stored.