LTX-2 Segment Queue Loop ??

The node that makes the LTX-2 loop actually finish

LTX-2 is the speed tier of local video - a 19B model that drafts clips in seconds where Wan takes minutes. But "seconds per clip" is the trap: the model's real ceiling is a few seconds of coherent footage, so any serious project is a chain of overlapping segments stitched into one long timeline. That's where this node earns its keep. It's the bookkeeping half of an LTX-2 extension loop: it takes whatever the current generation pass produced, saves it as a named segment, and hands the loop a bridge frame so the next segment can continue where this one stopped.

Think of it as the "save and advance" pedal. It's an output node, so it runs at the end of the graph, and it returns nothing - its whole job is side effects and queue management.

What it does with your frames

Feed it the output of a pass as video, images, or audio (they're all optional, but at least one is the point). It writes files to ComfyUI/output/ under filename_prefix (default IAMCCS/LTX2_segment), keyed by render_id and current_segment, so segment 3 never clobbers segment 2. Two flags control what survives: keep_segments keeps every saved pass, and merge_segments decides whether passes should be considered parts of one output or independent clips.

The clever bit is the bridge. With save_last_frame_bridge on, it saves the last frame(s) as bridge_name (default ltx2_detailer_bridge), and that frame becomes the anchor image for the next pass - the standard continuation trick that keeps a person or scene from drifting. trim_head_frames and trim_head_frames_on_continuation chop duplicated head frames off the current segment before saving, because in an overlap-based extension every pass except the first borrows frames from the one before it.

The two inputs that actually matter

• current_segment / total_segments - the loop counter and its bound. These are force-input INTs, so wire them from whatever is driving your loop (a forLoopStart or an index counter), not from the widget.
• enabled - kill switch. Turn it off and the node does nothing, which is handy when you're iterating on one segment and don't want the queue firing.

There's a deliberate safety rail: if you run a fresh graph with current_segment > 0 and no render_id or segment_base_name, it raises - it refuses to silently start mid-run. Set a render id, or reset the counter.

Installing it

This ships in the IAMCCS-nodes pack, so you get the whole family at once. Easiest is ComfyUI Manager: search for "IAMCCS" and install. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Then restart ComfyUI. No model downloads, no pip extras - the pack needs a recent ComfyUI (0.3.x+), Python 3.12+, and Torch 2.8+ per the author, which you almost certainly have if LTX-2 runs at all.

Where people get burned

The classic failure is a "Fresh run is starting from segment N" error - that's the guard above doing its job; give it a render_id or zero the counter. Second: forgetting that the bridge frame is only as good as the pass that produced it. If the current segment is a dud, the next one inherits the dud. Watch the bridge_name output path, not just the final video. It's a utility node, not a magic wand - but once it's wired, long LTX-2 shots stop being a manual save-every-pass chore.