- September 1, 2020 at 11:03 pm
I’ve tried different attsached drives and get a – 50 error.
I tried rendering back to the source drive and got this message, “Video rendering error: 10008 (The operation couldn’t be completed. Error processing frame, 20.9 Vesuivius Flt.49 Footage @ 00:00:21;15 <>)”
It’s just 16 .mxf files to which i have dded a source timecode burn.
- September 2, 2020 at 12:31 am
[Ty Ford] “I’ve tried different attsached drives and get a – 50 error.
I tried rendering back to the source drive and got this message, “Video rendering error: 10008 “
That typically means there’s something wrong with the source clip: https://support.apple.com/en-us/HT210757
Using the clip name and timecode info from the error message, select the clip in the timeline, do a SHIFT+F, locate it in the Event Browser, then right-click and reveal that clip in Finder and verify it is OK and playable.
If OK, disable background rendering in FCPX preferences, then delete all render files via File>Delete Generated Library Files>Delete Render Files>All.
Then reboot the machine, start FCPX, select all clips in the timeline via CMD+A then render them to cache via CTRL+R. If that hangs or crashes, state the error. If it completes then export using this preset: File>Share>Master File>Settings, Format: Computer, Video Codec: H.264 Faster Encode, Resolution: 1920 x 1080.
- September 2, 2020 at 1:34 pm
Thanks for your thoughts on this.
First, let me ask another question. This is a list of clips, all of which need a TOD Source time code burn.
After assembling them and dropping in the timecode window, I coudn’t export the session until all of the timecome windows were burned. The total length of clips was over an hour, so it took some time. A friend who uses Premiere, said he doesn’t have to wait for that render. Should I have background render enabled?
My client brought me two drives. One with the source clips, and a delivery drive. I think the rendering problem may have more to do with me trying to put the .fcp file on the source clip drive, doing the edit and trying to export to the delivery drive to save space. I tried moving things back and last night was able to render from my drive to his source clips drive.
I’m running a 2018 iMac with SSD. It’s pretty fast, but I needed more I/Os so I got a OWC thunderbolt 3 Dock. I think I had his drives connected to the Dock and the Dock connected to the iMac. The success I got happened after I connected more directly to the iMac. We have another such project to do today, so maybe I’ll have more intel. My take is that the OWC Dock is part of the problem. I’ve had things get weird when using it before.
- September 2, 2020 at 2:14 pm
[Ty Ford] “a list of clips, all of which need a TOD Source time code burn.
After assembling them and dropping in the timecode window, I coudn’t export the session until all of the timecome windows were burned. The total length of clips was over an hour, so it took some time. A friend who uses Premiere, said he doesn’t have to wait for that render. Should I have background render enabled?”
On my machine I can drop the built-in FCPX timecode *effect* on the first clip in the timeline, adjust position and other timecode parameters, then do CTRL+C to copy those attributes, select all other clips in the timeline and do SHIFT+CMD+V to paste that attribute to them all. After that I can immediately export without rendering, and I have background rendering off.
On FCPX you don’t have to render before exporting. As part of the export process it will automatically render a few frames, encode those, write to the output file, then move down the timeline until it’s finished. This is transparent and invisible.
The other approach is render all or part of the timeline which is written to cache files, then export. That rendering can be manual, by selecting clips (or all clips with CMD+A) and rendering them with CTRL+R, or it can be background rendering — they do the same thing. If rendered cache files exist, FCPX will ideally use those to expedite the export, doing just the encoding portion.
One reason some people don’t use background rendering is there’s no built-in file cleanup. As each batch of render files are marked invalid, they just pile up, taking up space. In older versions there were some issues with background rendering and lots of people became accustomed to turning it off.
The reason why I mentioned manually rendering is you described an export hang which can happen either during the render phase or encode phase. The first investigative procedure is disable background rendering, delete all render files, reboot the machine, then manually render the timeline with CMD+A and CTRL+R, then export using the above-listed H264 “fast” preset. You don’t normally have to do this, it’s an investigative procedure.
I don’t understand what you mean by “coudn’t export the session until all of the timecode windows were burned”. Can you provide more details?
- September 3, 2020 at 11:05 pm
Thanks so much for the detailed information. I printed out your response and will tape it to my monitor.
Very helpful. I’m beginning to think I may have just needed a restart. My subsequent burns went without problems.
—I don’t understand what you mean by “couldn’t export the session until all of the timecode windows were burned”. Can you provide more details?—
With background turned on, when I tried to export a session, I got a widow that said there was something going on that had to finish before I could export. There was the dotted line above the timeline, so I figured the system was rendsering the timecode windows and needed time to do that first.
Later, I did a couple of things including turning off background and restarting and things got better.
Thanks again. Client was happy.
Log in to reply.