KRuins - Render ETA

Most ComfyUI utility nodes are plumbing - carrying values, switching branches, cleaning up noodles. This one carries nothing. It sits on your canvas, watches, and tells you how long you've been waiting and how much longer it'll probably be. That's the whole pitch, and if you've ever queued a four-image batch at 20 steps and alt-tabbed away, it's a decent one.

What it actually is

KRuins - Render ETA is a display node. No inputs, no outputs, no data through it. You drop it anywhere in the graph, queue a prompt, and it shows a live elapsed clock, a progress bar for the sampling pass, a step counter (12/20), and an estimated time remaining.

Worth being straight about the tradeoff: ComfyUI's own frontend already draws a progress value on whichever node is currently executing. This node gives you a fixed readout in one spot on the canvas, with wall-clock elapsed time and an estimate for the sampling pass specifically.

How it works under the hood

The Python side is almost a joke. KRRenderETA declares an empty required dict, RETURN_TYPES = (), OUTPUT_NODE = True, and its run() method returns {"ui": {"status": ["Ready"]}}. That's it - 35 lines including the mapping dict.

Everything visible is drawn by js/kr_render_eta.js, which registers a frontend extension and listens to ComfyUI's websocket events directly: execution_start, executing, progress, execution_success, execution_error, execution_interrupted. A 250 ms timer repaints the canvas. When progress fires with value/max, it computes seconds-per-step as samplingElapsed / (stepsDone - 1) and multiplies out the remainder.

That - 1 is the detail that makes the estimate usable. The first step of a run absorbs model load and cache prep, so counting it would inflate the per-step average and leave you staring at an ETA you'll never hit. It waits for at least two steps before it shows a number at all.

One more piece of engine trivia you can see in the source: the node's IS_CHANGED returns float("NaN"). That's the standard idiom for forcing an output node to re-execute on every queue, since NaN != NaN always. Here it's how the timer resets for each new run. Standard idiom, and harmless here: nothing sits downstream to lose its cache.

Inputs and outputs

There are none. Literally none. It's an output node with zero sockets, which is why the README notes it "monitors execution without requiring a connection to another node." You don't wire it, you don't set anything, you just place it.

Installing it

It ships in a five-node pack. ComfyUI Manager is the easy path - search KRuins ComfyUI Node Suite - but note the README's own hedge: Manager install depends on the package being published to the Comfy Registry, and this pack is new and barely discussed anywhere. If Manager doesn't find it, clone:

cd ComfyUI/custom_nodes
git clone https://github.com/Rampart187/KRuins-ComfyUI-Node-Suite.git

Restart ComfyUI and look for the KRuins category. There's nothing to download - no models, no extra pip packages beyond numpy and Pillow, which ComfyUI already has. The pack declares no requirements.txt and no install script.

Where people get burned

The node isn't there at all. The pack's __init__.py imports all five node modules at the top level, and the Save Video module does from comfy_api.latest import io, ui, Input, Types. On a ComfyUI build that predates the V3 node API, that import raises and the entire pack fails to register - including this one, which has nothing to do with video. If a fresh clone adds zero nodes, check the console log for an import error before assuming the clone went wrong. Updating ComfyUI fixes it.

It sits at "Waiting for sampling progress" and never moves. The node gets its numbers from the global progress event, so any sampler that doesn't emit standard step progress - some custom samplers that drive their own bar - leaves it in the dark. The clock still runs; the estimate won't.

The ETA jumps backwards on a hires-fix pass. By design, actually. When the total step count changes mid-run, the code throws away the old sampling start and recalculates, because the second pass has a different steps-per-second profile. Same thing happens if you queue a batch: one timer spans the whole queue and only resets when the next queue starts.

It's optimistic on upscales. The remaining-time figure covers sampling only. VAE decode, tiled upscaling, and writing files all happen after the number hits zero, which on a big upscale can be a third of the total wait. The README says as much; treat the estimate as "sampling is nearly done," not "the picture's about to appear."