Wan Prev Tail Prep

Here's a subtle bug that eats hours in long-video work: you generate a segment with an end-frame lock, then decode it and feed the whole thing back as prev_samples for the next chunk - and the next chunk inherits the locked, frozen tail, so your motion dies on arrival. IAMCCS_WanPrevTailPrep ("Wan Prev Tail Prep") is a two-input cleanup node that exists to stop exactly that.

It takes a finished latent_in, and its whole job is to trim the tail that shouldn't be carried forward:

• locked_tail_slots - how many final slots were hard-locked to the end frame (your end_lock_slots from the motion node). Those are frozen by design, so remove them.
• overshoot_trim_slots - how many overshoot slots were added past the visible end (trim_slots from a motion node with end_overshoot_slots > 0). Those shouldn't exist in the final video either.

Set those to match what the motion node produced, and you get back a prev_samples latent that starts your next segment from the real last visible frames - motion intact, no frozen tail, no overshoot padding.

The three outputs

• prev_samples - the cleaned latent, ready to feed the next segment's motion node.
• slots_trimmed - how many slots it actually cut, so you can sanity-check your numbers.
• video_frames - the frame count that survives, for wiring into a length or duration check.

How it fits

This is the bookend to WanImageMotionPro's FLF behavior. The motion node locks the end and adds overshoot; this node removes both before the loop continues. If you're chaining segments with end-frame convergence, WanPrevTailPrep is the difference between "first segment perfect, everything after drifts" and a clean long take. It also pairs naturally with IAMCCS_WanImageBatchFrameSelect when you're working in decoded-image space rather than latent space - same idea, different data type.

Install

Standard IAMCCS-nodes:

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

or ComfyUI Manager → search "IAMCCS" → restart. No models, no dependencies. ComfyUI ≥ 0.3.0, Python ≥ 3.12, Torch ≥ 2.8.

The trap

It only works correctly if you feed it accurate numbers. If you tell it to trim zero locked slots when the previous segment actually locked one, you're back to the frozen-tail problem - the node can't detect the lock, it just obeys. So wire overshoot_trim_slots from the motion node's trim_slots output rather than typing a guess, and treat slots_trimmed as the confirmation that your arithmetic was right.