IAMCCS_Ltx2HelperModules Disk Extension

If your system RAM is the wall you keep hitting on long LTX-2 runs - and for a lot of people it is, 64GB is the comfortable floor and everything below starts swapping - then DiskExtension is the node you want at the stitching step. It's Continuity's disk-based twin: instead of holding footage as IMAGE tensors in memory and stitching there, it reads PNG frame directories, stitches on disk, and writes the result back out. Same idea as IAMCCS_LTX2_ExtensionModule_Disk, but wired into the helper-module chain so the planner and refresh payloads drive it automatically.

The low-RAM story in this pack is a real pipeline, not a single node: VAEDecodeToDisk writes frames one at a time, DiskExtension stitches them on disk, and a disk→latent node reads the result back for the next segment. This node is the middle of that.

How it works

It wraps IAMCCS_LTX2_ExtensionModule_Disk.process_extension_disk, and like Continuity, it lets the chain configure it:

• source_dir - the accumulated frames so far (default iamccs_extension_disk/loop_seg0_extended).
• new_dir - this segment's freshly generated frames (default iamccs_vae_frames/loop_audio_sync/current).
• output_dir - where the stitched sequence lands (default iamccs_extension_disk/loop_extended).
• start_dir - the start/overlap frames for the next pass (default iamccs_extension_disk/loop_start).

From planner_payload it pulls recommended_overlap_frames; from refresh_payload it gets the segment role, the effective continuity preset, and - on reanchor segments - the reanchor overrides for overlap_mode, safe_mode, and start_frames_rule. So a reanchor segment gets its filmic crossfade and 8n+1 start-frame rule without you touching anything; a continuity segment stitches with the continuity preset. That's the whole automation story: you maintain the directories, the chain maintains the settings.

Like the standalone disk module, this always reruns (ComfyUI treats it as permanently changed), because it mutates directories on disk and stale cached results would be actively wrong.

The inputs and outputs that matter

Set the four directory paths once, then wire planner_payload and refresh_payload from the chain. That's the real interface. Outputs you'll use: extended_dir and start_dir_out (STRING paths - feed them to the next disk step), overlap_frames, calculated_frames, extension_frames INTs, plus disk_payload, contract, linx, and report.

Installing it

Ships in IAMCCS-nodes under IAMCCS/Ltx2 Helper Modules. Manager → "IAMCCS" → install, or:

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

Restart ComfyUI. No models. The surrounding low-RAM pipeline needs the pack's VAEDecodeToDisk and disk-to-latent nodes plus ComfyUI's LTX nodes.

Common issues

Directory collisions are the top failure: this node always reruns and writes fixed paths, so two workflows (or two parallel instances) sharing a directory will clobber each other. Give each project its own directory tree. Second, new_dir contents must actually exist - if the segment generation failed upstream, this node stitches whatever's in source_dir and you get a clip that silently didn't grow; check the report (it records what it processed) before assuming success. And the usual disk-based caveat: the start_frames_rule matters more here because a wrong start-frame count surfaces as an encode failure a full segment later, and on a disk pipeline that's a slow, expensive discovery.