[ccoventry]

Release note: Fixed: The capture batch's progress bar fills once from start to end and says each step in plain words ("Getting demos ready", "Starting the game", "Loading…", "Capturing clip 3 of 12", "Checking the takes"), with a clock and "Done in 6 min 12 s: 12 clips captured" at the end.

Closes #952 (from the #942 audit).

What changes

• One bar for the whole batch. Getting the demos ready fills the first tenth, the clips the rest (10–98%), and checking the takes the last bit. The bar never goes backwards, and the made-up 50% is gone.
• A step it can't measure keeps the fill and slides a block over that step's share: the decal pass while a demo is patched, starting the game, loading a demo, and the clip being recorded (the block covers the next clip's share).
• Plain step lines. These come from messages.rs, with the step texts from the plan:
  • "Getting demos ready…" shows the moment the batch starts.
  • "Reading name.dem again for its clip times (1 of 3)".
  • "Getting demos ready: 2 of 5 (name.dem, 40%)". "Patching" and "clearing decals" are gone.
  • "Starting the game for name.dem (demo 1 of 3)".
  • "Loading name.dem…". This comes from the DEMO_START marker, which used to reach only OS notifications.
  • "Capturing clip 3 of 12 (name.dem) · about 4 min left".
  • "Checking the takes: 12 of 12".
• A clock runs on the line (· m:ss) from the first report to the end.
• The end line: "Done in 6 min 12 s: 12 clips captured", or "10 of 12 clips captured" when some takes are missing. A cancelled or failed batch reads as before.
• The activity log gets [capture] started and [capture] completed after 372.0 s: 12 of 12 clip(s) captured.

How

• Backend (Rust): every running capture_status now carries a stage (preparing, reading_again, starting, loading, capturing, checking) and its count. The patch line keeps its ~33 ms throttle (PatchProgress), and the take check is throttled the same way.
• Takes are checked before the batch reports its end. The order is now: "Checking the takes" → running: false with clips_captured/clips_total → capture_takes_verified. Start stays greyed out through the check, and the footer's last line still comes before what Finish clips puts on it.
• Frontend: the logic lives in a new module, capture_progress.js (shares, the never-go-back rule, the end line, the clock and the time left). capture_pane.js only calls it, and its own 50% fallback and 15 s timer are gone.
• Shared pieces:
  • durationWords is new in progress_view.js (the shared helper from Master Queue scan: show progress while it looks for demos, and one bar through grouping and splits #951).
  • showFillAndSlide is split out of step_bar.js (HD Textures and Blender show progress as text only: add bars #956's sliding block over one step's share).

Decisions

• The shared sliding-block helper was already on dev (progress_view.js from Master Queue scan: show progress while it looks for demos, and one bar through grouping and splits #951, step_bar.js from HD Textures and Blender show progress as text only: add bars #956), so I reused it rather than building a new one.
• Shares:
  • Reading again 0–5%, patching 5–10%, clips 10–98%, checking the takes 98–100%.
  • Most batches seek between clips, so they have no patching. For them the bar starts at 10% when the game starts, after the block has slid over the getting-ready share.
• "(demo 1 of N)" only shows when the batch has more than one demo. The game opens once for the whole queue, so the line names the batch's first demo.
• Several demos patched at once: "Getting demos ready: 1 of 5 done, 4 at once (40% on average)".
• The engine's "Finished" report no longer sends a line of its own. The take check that follows it at once says what's happening.
• The OS notifications ("Patching 3 demos") are not changed. The plan covers the footer only.
• Capture batch bar fills twice and sits at a made-up 50%: one bar with plain steps #952 said to start 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 merged. The pass brief asked for it now, so this branch is off dev, and whichever merges second resolves the conflict (see below).

Other open PRs touching the same files

• capture_manager.rs / capture_pane.js: 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 (render while capturing: changes verify_capture_takes / emit_take_verification, which this PR splits into check_takes + finish_batch; expect a conflict there), Scheduled Commands can run for only some players' clips (a crosshair per player) #832, Studio marks clips captured after a batch that ran while it was closed (part of #545) #760, Delete finished takes automatically: Recycle Bin or permanent, optionally only when space is needed (part of #644) #716.
• messages.rs: Review marks are kept with no project open and come back when you add the demo later (part of #848) #881, 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.
• strings.js is touched by most open Studio PRs. This PR adds a CAPTURE_PROGRESS block and drops three strings nothing uses now (CAPTURE.COMPLETED, capturingWithName, CAPTURING_DEFAULT).

Test done

• cargo test --locked -p desktop-studio: 236 passed. New tests cover the getting-ready line and the step texts.
• rustup run 1.98.1 cargo clippy --locked -p desktop-studio --all-targets -- -D warnings: clean. rustup run 1.98.1 cargo fmt --all: no changes.
• npm run test:unit: 864 passed. New: capture_progress.test.js (the shares, the never-go-back rule across a whole batch, the end line, the clock and the log lines) and durationWords.
• Playwright (CI=1): capture-progress.spec.js (new), capture-precheck, finish-clips, batch-results and app-boot: 19 passed. The new spec has the e2e check the plan asks for: the bar never goes backwards across the stages and ends at 100% on "Done in". It also checks the sliding block and the cancelled line.
• No live batch was run (an unattended pass, no game).

Test steps for you (no hook DLL change, either install)

1. A batch that seeks between clips (the default), 2+ demos, 3+ clips, on PRE:
   • Start Capture Batch: after the checks, the line says "Getting demos ready…" with a block sliding over the start of the bar.
   • The game starting: "Starting the game for X.dem (demo 1 of N)".
   • Each demo: "Loading X.dem…".
   • Each clip: "Capturing clip k of N (X.dem) · about … left · m:ss". The bar fills by clips and a block slides over the clip being recorded.
   • After the game closes: "Checking the takes: N of N", then "Done in … : N clips captured". The bar never jumps back at any point.
2. The same with Seek Between Clips off (a patched batch): "Getting demos ready: 1 of N (X.dem, 40%)" fills the first tenth, then the clips carry on from there without dropping to 0.
3. Cancel partway: the line says "Cancelled" and the bar empties.
4. The activity log: it has [capture] started and [capture] completed after … s: … clip(s) captured.

🤖 Generated with Claude Code

[ccoventry]

Review (night pass 2026-10-25)

Read: the whole diff: the Rust (PatchProgress, check_takes/finish_batch, the step lines) and capture_progress.js, capture_pane.js, step_bar.js and progress_view.js.

• main.js is untouched.
• Every capture_status comes from the blocking or listener threads.
• The take check is throttled to 33 ms.
• log_frontend_event already has its .catch.
• DEMO_START's 1-based index counts only jobs with clips (the primer has none), so demo_names lines up for both patched and hook-run batches.

Found and fixed: Cancel came back on while the takes were checked (d47417ab).

• The Cancel click's .then clears capturingInFlight straight away, before the game closes. The check that follows sends running: true ("Checking the takes"), so it re-entered the "first report of a batch" branch.
• That branch turned Cancel back on and called batchStarted() again.
• On a normal end, Cancel was also on during the check, which can't be stopped.
• Fix: a running report starts a batch only when captureProgress isn't already running one, and Cancel is greyed out for the checking stage.
• Test: a new e2e test in capture-progress.spec.js. It fails without the fix.

Ran (after merging dev in, head 955aa269):

• cargo test --locked -p desktop-studio: 236 pass.
• Pinned clippy and fmt: clean.
• npm run test:unit: 864 pass.
• Playwright: capture-progress, capture-precheck, finish-clips, batch-results and app-boot, 20 pass.
• CI is green.

Screenshots: from the harness, with Studio's CSS, one per step from "Getting demos ready…" to "Done in": local\review-images\952\. The real app wasn't driven: a capture batch can't be faked there, and another dev server holds port 5173.

#885 conflict, for whichever merges second: git merges the two cleanly, but the build then fails. #885's new test calls verify_capture_takes(&manifest), and this PR gives that function a second argument. The fix is verify_capture_takes(&manifest, &mut |_| {}). I checked this with a trial merge plus cargo test --no-run. #885's rendered-and-deleted takes count as captured, so "Done in …: N clips captured" stays right after both land.

Left as is: "No jobs produced" is sent as running: false with no error. It used to read "Completed" and now reads "Done in 0.2 s". That path was already wrong before this PR, and it's rare.

Verdict: ready to merge. The look follows #952's plan.