Video Frame Guard (<=210 frames)

Flag this one before anything else: the VHS_ prefix is normally shorthand for kosinkadink's ComfyUI-VideoHelperSuite, one of the most widely used video packs in the whole ComfyUI ecosystem - real community threads reference VHS_LoadVideo errors constantly. VHS_VideoFrameGuard is not part of that pack. It ships from comfyui-sortlist, reuses the prefix (presumably because it operates in the same territory - video path validation), and has no connection to VideoHelperSuite's codebase or maintainer. If this node ever throws an error, don't go digging through VideoHelperSuite's GitHub issues looking for it - you won't find it there.

What it actually does

It's a pre-flight sanity gate for a batch of video files, meant to run before you commit to something expensive - generation, upscaling, a long render - on clips that might be too long to handle.

• paths - a multiline STRING, one video path per line presumably.
• max_frames - INT, default 210. Your cap. Any clip estimated to exceed this fails the check.
• force_rate_fps - FLOAT, default 0 (meaning: use each file's own reported fps). Set it nonzero to see what the frame count would be if the clip were re-timed to a different fps before it hits your generator - useful when your downstream pipeline is going to resample anyway and you want the check to reflect that.
• raise_on_fail - BOOLEAN, default true. With this on, a failing clip stops your workflow outright. Turn it off if you'd rather just get a report and decide what to do yourself.

Outputs: all_ok (BOOLEAN pass/fail summary), valid_paths and invalid_paths (STRING, the sorted survivors and rejects), and report (STRING, human-readable detail on what failed and why).

Where it fits

Run this before a batch of clips goes into any video model with a hard frame-count ceiling. It catches the one outlier clip that would otherwise blow past your VRAM budget or get silently truncated several expensive steps deeper into the graph - much cheaper to find out here than after a generation run has already burned time and compute. It pairs naturally with VHS_VideoPickMinFrames: run Frame Guard first to filter out anything over your cap, then feed the survivors into Pick Min Frames to find your actual shortest clip for syncing a batch.

Installing it

ComfyUI Manager: search comfyui-huyl2-nodes - not VideoHelperSuite, which is a separate, unrelated pack you may already have installed. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/huyl3-cpu/comfyui-sortlist

restart. Not documented in the pack's README, which covers a single unrelated node. Frame-count estimation from video files typically leans on ffmpeg/ffprobe or OpenCV under the hood - if this errors with an import or "command not found" message, check that whichever it uses is actually available in your environment, especially if you're not running the author's preconfigured Colab setup.

Common issues & troubleshooting

If ComfyUI reports a VHS_ node is missing or conflicting and you already have VideoHelperSuite installed, don't assume it's a duplicate - check the pack it actually resolved to. Two different packs shipping a node with the same prefix is exactly the kind of dependency confusion this ecosystem is prone to (custom nodes have no namespace isolation from each other by design), and it's worth a look at ComfyUI's startup console log to confirm which comfyui-sortlist vs. VideoHelperSuite node actually loaded if something behaves unexpectedly.

Otherwise: a clip failing the check when you expected it to pass is usually a force_rate_fps mismatch - if your downstream pipeline resamples to a different rate than the source file's native fps, set this field to match, since the frame-count math is sensitive to what fps it's estimating against.