Check Total Frame

The long-video nodes in this pack take a chained vace_prompt_list and produce one stitched video. The question you always want answered before queueing something slow is: how long is that video going to be? VACEPromptCheckTotalFrame is the pocket calculator that answers it. It reads your prompt chain and returns the total frame count the long-video node will generate.

How it works

One input, one output. Feed it a prompt_list (the PROMPTLIST from your last VACEPromptCombine) and it sums up the lengths:

total_frame = Σ (num_frame − init_crossfade_frame) over every round.

That's the exact same arithmetic the long-video nodes use internally, which is why the number is trustworthy. The init_crossfade_frame frames are overlap, not new content - the node subtracts them per round, so your "9 rounds × 81 frames" isn't 729 frames, it's 81 + 8×(81−5) = 689 with the defaults. That's the number that actually gets rendered.

Output is total_frame as an INT, which you can display with a Show Text/primitive node or feed into downstream math - for example, to sanity-check control positions before you build the control list, or to set loopback and save steps.

Why you'd bother

Long VACE renders are expensive - every round is a full VACE generation. The two ways this saves you pain:

1. Timeline planning. VACE Control Image Combine positions are measured against the total length. Knowing the exact total means you can lay out keyframes and pose/depth segments without guessing and hitting the overlap errors mid-run.
2. The "it's shorter than I thought" surprise. People set up nine rounds, assume the math, and then discover the real count at the end. This node makes the count explicit before the first frame samples.

Install

Same pack, same line:

cd ComfyUI/custom_nodes
git clone https://github.com/bbaudio-2025/ComfyUI-SuperUltimateVaceTools

Restart ComfyUI (or search "SuperUltimateVaceTools" in Manager). No dependencies.

Gotchas

• It only reads the list you hand it. If you add a round after this node in the chain, or change a num_frame, the number goes stale - re-run it.
• It gives frames, not seconds. At 16fps, 689 frames is ~43 seconds; at 24fps it's ~29. The node won't convert for you, and converting wrong is a classic way to mis-plan.
• The first round's init_crossfade_frame gets subtracted here even though that round has nothing to crossfade from - the long-video node's own internal total does the same. Result: with the default of 3 on round one, the actual rendered video comes out three frames longer than the number this node reports. Small, but if you're positioning a control exactly on the last frame, it matters.

It's the most boring node in the pack and honestly one of the most useful - two seconds of wiring, zero wasted renders from miscounting your timeline.