Snap Frames to boundry rules

LTX and Wan both enforce frame-count rules that are easy to get wrong and tedious to compute by hand. LTX wants 8n + 1 frames (1, 9, 17, 25...), Wan wants 4n + 1. The README's warning is blunt: if you don't snap frames you might get errors or bad renders. Snap Frames exists to make that arithmetic a dropdown instead of a math node.

The author's own framing says what it replaces: "This avoids the clumsy math expressions that are normally required in the workflow." If you've ever kept a ((frames-1)//8)*8+1 expression alive in your graph and prayed the parentheses were right, you know exactly what this node is for.

How it works

Two inputs, one output. model is a dropdown - WAN (default) or LTX - which picks the divisor (4 or 8). num_frames is the frame count you'd like to use. The node rounds it up to the nearest valid multiple × n + 1 and hands back snapped_frames. That's the entire mechanism:

• LTX: ceil((n-1)/8) * 8 + 1
• WAN: ceil((n-1)/4) * 4 + 1

Rounding up (never down) matters: models enforce these as minimums, and coming up one frame short is the failure mode that produces errors or a render that silently drops content.

Where it slots in

Wire it between your frame-count source (a duration calc, a video-input node, a chunker) and your empty-latent/sampler frame input. Because it's a single INT out, it plays nice with anything that takes a frame count. It's the lightweight sibling of TKCalcLTXFrames - that node handles the full chunk+overlap+trim dance for LTX chunking, while this one just snaps a bare number, which makes it the better fit when you only need the boundary math and not the overlap bookkeeping.

Common issues

Two things trip people up. First, remember LTX uses 8 and Wan uses 4 - the node defaults to WAN, so if you're on LTX and leave it, every count comes out valid-but-wrong-sized for LTX's stricter grid, and since it's still n+1 the model may accept it while your timing drifts. Second, snapping rounds up, so feeding it 97 frames for LTX returns 97 if it's already valid, but 95 would snap to 97 - your num_frames and your snapped_frames may not match, and that's the feature. If you need the exact original value preserved too, keep a second wire from your source rather than deriving it back from the snapped output.

Also worth noting: this is a ComfyUI-side safety net for the model's inference grid - it doesn't change video encoding or container rules. It's the "feed the sampler a valid count" fix, not a frame-rate conversion.

Installing it

Part of trashkollector/TKNodes ("ComfyUI Handy Nodes"). Install via ComfyUI Manager (search "Handy Nodes") or:

cd ComfyUI/custom_nodes
git clone https://github.com/trashkollector/TKNodes

Restart, and it's under TKNodes. One dropdown, one integer, zero dependencies.