[ccoventry]

Release note: Fixed: The Render tab's batch bar starts at 0 for each new batch instead of counting takes rendered earlier, and shows the time left and "Done in" at the end. Scan for Takes shows a moving bar while it looks.

Part of #954 (from the #942 audit). The finish-clips wait is left for after PR #885, as the plan says.

What changes

• The batch bar and its line count only this batch's rows.
  • Rows that an earlier batch finished stay in the table (Scan for Takes should work at any time and merge into the queue #772), and the bar used to count them, so a new batch could start at "Batch 60%" and "(6/10 done)". The batch's own rows were already kept for the end toast; that list now drives the bar and the line too.
  • The bar is hidden until a batch starts. Rows a scan queued are not a batch yet.
  • Once a batch ends, the bar keeps showing how it ended until the next batch starts.
• The line while it renders: "Rendering 3 of 10 · about 4 min left · 1:23". The time left comes from the frames left at the pace so far, and only shows after the first 5 s (FFmpeg starting up isn't its pace). It moves every second along with the clock.
• The end line: "Done in 7 min 40 s: 10 rendered", or "Done in 42 s: 8 rendered, 1 failed, 1 cancelled". A batch where everything was cancelled still says "Status: Cancelled", in the same colours as before.
• Scan for Takes:
  • While it looks, a block slides under the status line and the line says "Looking for takes: 14 found so far · 0:02".
  • At the end the line says "Found 14 takes (3 new) in 2.1 s".
  • The "Scanning render directories..." toast is gone; it only repeated the line. The toast at the end stays.
• The activity log gets [render] started and [render] done after 460.0 s: 10 rendered, 0 failed, 0 cancelled.

How

• Backend (Rust, render_manager.rs):
  • render_scan_status now sends { found: N }, at most every ~33 ms (ScanCountThrottle), and once more at the end. It used to send one event per take with the take's name, which the frontend only counted.
  • The batch's snapshots (render_jobs_snapshot, from the 150 ms scheduler) are unchanged.
• Frontend:
  • The logic lives in a new module, render_batch_progress.js: the batch's rows, frames done and left, the time left, the lines and the batch clock with its log lines. render_pane.js only calls it.
  • batchEndStatus takes the batch's length and says "Done in".
  • The sliding block and clock come from progress_view.js (Master Queue scan: show progress while it looks for demos, and one bar through grouping and splits #951). durationWords is the same addition as in PR Capture batch: one progress bar from start to end, with each step in plain words and Done in at the end (#952) #1025, in the same place, so the two PRs merge cleanly.

Decisions

• "Rendering N of M": N is the next render to finish (finished or failed, plus one), matching the capture's "Capturing clip 3 of 12". Cancelled rows drop out of M.
• The scan's bar is a new thin bar under #render-status, not the batch bar, because a scan can run while a batch renders.
• The finish-clips wait ("waiting for the Render tab…") is not in this PR. The plan says to do it after PR Render while capturing: each clip renders as soon as it's recorded, and a long batch waits for space instead of filling the drive (#861) #885, which reworks that footer. So this PR is "Part of Render tab batch bar counts rows from earlier batches, and Scan has no bar #954" and links nothing.
• The scan-end and batch-end lines drop the "Status:" prefix, as Master Queue scan: show progress while it looks for demos, and one bar through grouping and splits #951 did for the queue. The other Render lines keep it for now.
• If Start is refused before anything renders, the batch is forgotten (no clock left running, no end logged).

Other open PRs touching the same files

• render_pane.js: A slow file dialog says it's on its way instead of looking frozen #1001, Render tab: Select finished ticks every take whose clips are done, to clear leftover takes in one go (part of #644) #997.
• index.html: POST: a setting to draw the game's menus at the pre-Anniversary size (#985) #1007, Render tab: Select finished ticks every take whose clips are done, to clear leftover takes in one go (part of #644) #997, Render while capturing: each clip renders as soon as it's recorded, and a long batch waits for space instead of filling the drive (#861) #885, Demo Auditor: move every demo into one folder, recycling the extra copies (#872) #874, Delete finished takes automatically: Recycle Bin or permanent, optionally only when space is needed (part of #644) #716 (this PR adds one line under #render-status).
• render_manager.rs: Render while capturing: each clip renders as soon as it's recorded, and a long batch waits for space instead of filling the drive (#861) #885, Delete finished takes automatically: Recycle Bin or permanent, optionally only when space is needed (part of #644) #716.
• tests/e2e/render-studio.html / .spec.js: Render tab: Select finished ticks every take whose clips are done, to clear leftover takes in one go (part of #644) #997.
• progress_view.js / progress_view.test.js: PR Capture batch: one progress bar from start to end, with each step in plain words and Done in at the end (#952) #1025 (Capture batch bar fills twice and sits at a made-up 50%: one bar with plain steps #952) adds the same lines.
• strings.js is touched by most open Studio PRs. This PR adds lines to RENDER and drops three it no longer uses: renderingStatus, scanFoundSoFar, SCANNING_TOAST / STATUS_SCANNING.

Test done

• cargo test --locked -p desktop-studio: 236 passed, including the new the_scan_count_is_sent_at_most_every_33_ms_and_once_at_the_end.
• rustup run 1.98.1 cargo clippy --locked -p desktop-studio --all-targets -- -D warnings: clean. rustup run 1.98.1 cargo fmt --all: applied.
• npm run test:unit: 861 passed. New: render_batch_progress.test.js (only this batch's rows, frames and time left, the scan's end line, and the batch's start, end and discard) and "Done in" in batchEndStatus.
• Playwright (CI=1): render-studio.spec.js, finish-clips and app-boot: 66 passed.
  • New: a second batch's bar starts at 0 (the e2e check the plan asks for).
  • New: Scan slides a block, counts the takes, and ends on "Found 14 takes (3 new) in … s" with no "Scanning" toast.
  • Updated: the batch-bar test now expects 50% where it expected 75%, because the Finished row from before isn't this batch's.
• Nothing was run live (an unattended pass).

Test steps for you (no game needed)

1. Render tab: Scan for Takes on a capture folder.
   • A block slides under the status line, and the line counts "Looking for takes: N found so far · 0:0x".
   • It ends on "Found N takes (K new) in X s". No "Scanning…" toast pops up at the start.
2. Render a few takes.
   • The footer bar starts at 0%, and the line reads "Rendering 1 of N · 0:0x". After a few seconds "· about … left" appears.
   • The end line says "Done in …: N rendered".
3. Scan again after new captures, and Start again. The bar starts at 0% again, although the earlier rows are still listed as Finished.
4. The activity log: it has [render] started and [render] done after … s: ….

🤖 Generated with Claude Code

[ccoventry]

Review (night pass 2026-10-25)

Read: the whole diff: render_manager.rs (ScanCountThrottle), render_batch_progress.js, render_pane.js, render_batch_status.js, strings.js, the harness and the tests.

• Scan events: scan_folder_background sends one status message per take, so counting messages is right. The scan count goes out at most every 33 ms, plus once at the end.
• IPC: the new render_scan_status listener has its .catch.
• Batch rows: Start adds every Queued row, and Start renders every Queued row, so the two agree.
• The bar: it is hidden until a batch exists. After a batch it keeps the last batch's rows, and the first row of a new batch replaces them.
• batchEndStatus: the colours are the same as before when no duration is passed.
• Merging with Capture batch: one progress bar from start to end, with each step in plain words and Done in at the end (#952) #1025: this branch and Capture batch: one progress bar from start to end, with each step in plain words and Done in at the end (#952) #1025 merge cleanly with each other (git merge-tree). Their identical durationWords lines don't conflict.

No bugs found.

Ran (after merging dev in, head aa4e43a6):

• cargo test --locked -p desktop-studio: 236 pass.
• Pinned clippy and fmt: clean.
• npm run test:unit: 861 pass.
• Playwright: render-studio, finish-clips and app-boot, 66 pass.

Screenshots: from the harness, with Studio's CSS: local\review-images\954\. They show:

• the scan's sliding block and "Looking for takes: 7 found so far";
• a second batch at 15% while two rows from the first batch are Finished;
• the end line "Done in 0.6 s: 2 rendered" with 4 rows Finished.

The real app wasn't driven: another dev server holds port 5173.

Known limits, not this PR's: a batch started by Finish clips (not the Start button) learns its rows from the first snapshot that shows Rendering. A take that finishes inside one 150 ms snapshot gap before that isn't counted. The end toast already had the same gap.

Verdict: ready to merge. It follows #954's plan for this part.