WAN Unconnect Frames

WAN Unconnect Frames is the cleanup pass for the connect/stitch workflow. It's the node you need precisely because the thing that made your sample good is the thing you have to remove afterwards.

The setup: a sibling node in the same pack, WAN Connect Frames, builds one Wan-valid internal sequence out of several clips - an optional start cap, your first section, a masked transition gap, an optional second section, an optional end cap, and masked gaps between all of them. Those caps aren't footage you want in your final render. They exist so the sampler has real temporal context before the first masked gap and after the last one, and so that frame counts land on 1 + 4n (the Wan VAE's ~4× temporal compression turns any other length into a short clip with duplicated frames at the tail - the "111 frames in, 109 out" problem). Scaffolding, in other words. WAN Unconnect Frames takes it back down.

What it actually does

Three inputs, all required, all from WAN Connect Frames: raw_frames (the full internal sequence - its raw_frames output, not frames), inpainted_frames (the context segment after sampling), and metadata, a forced STRING input.

It parses the metadata (format link-comfy-nodes/wan-connect-v2), then does three things in order. It drops the padding frames that were added to the segment purely for length, keeping only the frames that correspond to real positions in the internal sequence. It pastes those kept frames back over the segment's span in raw_frames - so the masked gaps are now filled with generated content while everything else stays exactly as it was. Then it deletes the indices listed in the metadata: the start and end caps and the length padding. What falls out is one output, frames - your core connection sequence, inpainted, with the removable scaffolding gone.

Two guards make it trustworthy rather than a wrapper. It verifies the raw count and the segment length against the metadata before touching anything, and it asserts the final frame count is still 1 + 4n afterwards, raising if it isn't. If you feed it mismatched batches you get "WAN Unconnect Frames received a different raw frame count than WAN Connect Frames output: metadata expects N, received M" instead of a silently wrong render - which, given that the alternative is discovering the problem after a twenty-minute video sample, is the right trade.

One naming note for anyone grepping: the class in the source is aliased WANRemoveCapFrames, and WAN Connect Frames is aliased WANBeginEndFrames, for older Python callers. Same nodes, older names. The registered node name is WAN Unconnect Frames, and its tooltips still describe itself as working on a "core connection sequence."

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/Mister-Link/link-comfy-nodes

or ComfyUI Manager, search Link Comfy Nodes, then restart. Two pack-level caveats worth knowing before you commit: the README is the whole sentence "AI slop nodes for my own purposes, use at your own risk (I change how nodes behave without warning)", and this pack has no community footprint I could find, so there's no forum thread where someone already hit your error. And the install is heavier than the node: requirements.txt pulls pytorch_lightning, mambapy, numba, transformers and a git-sourced clip @ git+https://github.com/openai/CLIP.git, none of which this node needs but all of which the pack's top-level __init__.py will insist on before any node registers.

Where people get burned

Wiring the wrong output into raw_frames. It must be the full internal sequence - the one that still contains caps and padding. If you pass the frames output instead, the count check fires immediately.

Trimming anything by hand. The metadata carries exact indices into the batch you gave it. Crop it, reorder it, drop a frame, or run it through a node that resamples the sequence, and either the count check or the final 1 + 4n assertion catches you. That's the point - but it does mean this pair needs a straight run from Connect → sampler → Unconnect, with nothing frame-mutating in between.

Expecting it to be a general-purpose stitcher. It only merges segments that came out of WAN Connect Frames with matching metadata. It is not a generic video joiner, and the pack's author is explicitly changing node behavior as he goes.