Like every 5 seconds or so, VEAI3 seems to pause, visually, and then resumes only after 10 seconds or so (and ETA increases drastically in the meantime). What is up with that?? Seems like a horrible bug.
And no, my video card isn’t throttling or anything; nor my CPU.
Hard drive disc? I ask because I just got a new 8TB HDD, and it pauses everything using it for like 10 to 30 seconds at a time will it does something. This happens as often as every minute to every few hours (The more read and writes queued to it, the more often it happens). Most programs just wait for it, but some fail.
It only seems to be happening when I put VEAI 3 to the foreground, and am looking at dual preview windows. If I put focus elsewhere, the taskmanager keeps all CPU’s at 100% (otherwise they go down a bit on the pauses).**
The disks are both high-speed SSDs, so that’s likely not it.
** I really hope the pauses won’t show up in the output (can’t check yet, as it’s ProRes 422 HQ, so mov needs to be finished first).
New tests done. GPU memory is not an issue. Highest ever used is 4G (out of an available 12).
Just ran a smaller test, and again with a weird second pass going on, at the end. What is this bizarre second pass??
I also don’t understand that completely. I think it has something to do with the great quantity of complaints in 2.6.4 that when something crashed while exporting to ProRes, all the work was lost.
To me it looks like it makes two copies, one that can be played after a crash, and a normal one. No idea what the second pass does though. Maybe checks them to see if one is better or the timings are all the same.
As far as I know it only does that with ProRes output.
That 2nd pass just finished (I let it complete, this time). And indeed, this one works. 
(I think .mov headers are always added when the file is done only). So, yes, it may be a crash-recovery support file. It had an extension of .prob3 (problem?), so it may indeed be used as a second pass, to potentially pick up where VEAI left off on an earlier crash.
Tl;dr: matter solved. It was human error (namely mine). Thanks for shedding light on this 2nd pass recovery pass.
EDIT: The pauses haven’t stopped, but, fortunately, don’t make part of the output file. (Could actually be the pauses are possible flush-moments, to forcibly commit data to disk, intermittently; and in case of ProRes, those be HUGE chunks). It’s all coming together now.
I have a 4090 and the same issue rendering to a SSD. It’s a preview issue, and I think actually loosely mentioned as a known issue in the 3.0.3 release notes.
Very loosely mentioned. 
But I can live with it, as the pauses don’t occur in the output file.
Yes - it throws off the rendering time estimate and the seconds per frame as well.
The estimate for these clips were 4.5 hours or so – but in reality it was over 5.5 hours.
