# Medium fresh-process image-only check

- Date: 2026-09-16 KST. Owner: test / ltb1021.
- Repository HEAD: 19c6353bf96f6caba9a0d377bdecf0ad7a0a7368; source unchanged, worktree clean.
- One fresh candidate-image trial, no Pose channel Start, no model/config changes or build.
- Existing Medium instance1/max_batch1, original Pose/Fire mounts and all model configs preserved.
- Tracking/Scenario Off, analysis10FPS, original three channel settings/identity/Anchor unchanged.

| Condition | Seconds | Result FPS 01/02/03 | Redis FPS 01/02/03 | Final queue | stale delta |
| --- | ---: | --- | --- | --- | --- |
| Existing image before test | 5.556 | 5.40 / 5.04 / 5.76 | 5.40 / 5.04 / 5.59 | 8 / 8 / 7 | 24 / 28 / 28 |
| Fresh candidate, Medium only | 20.371 | 9.97 / 10.01 / 9.97 | 10.01 / 9.91 / 9.97 | 0 / 0 / 0 | 0 / 0 / 0 |
| Original image recreated | about5 | 10.24 / 10.06 / 10.06 | 10.06 / 9.87 / 9.89 | 0 / 0 / 0 | 0 / 0 / 0 |

Candidate queue maximum 0/1/1; result capacity drop0. Publisher latest pending Frame replacement3,
no observed send-error/expiry increment; workers3/control1/retiring0, detailed diagnosticsOff.
Redis stored100 entries per channel with renewed TTL. Snapshot timing differences limit direct FPS equality.
Candidate resources: container CPU about2.01 logical-core equivalents, memory1181-1204MiB;
global GPU memory4921MiB, utilization27-30% sampled. These are not proof of absent fine-grained contention.

## Interpretation

The previous claim that only the new image slows Medium is not supported: the original image was already
slow before this trial. Its infer/native counters were about9.5-10.3FPS while result completion was5.0-5.8FPS.
The candidate in a fresh process did not reproduce the slowdown in20seconds. This does not establish
long-run health or Pose correctness, and does not prove the mux/pool change causes or fixes the issue.
Run age, accumulated state, scene-dependent result work and shared scheduling remain unseparated.
No extra trial or profiling was performed. Next minimal observation would be the first native-to-result
slowdown over run age with bounded result-worker timing, rather than another batch/instance change.

## Restore and helper note

Original image/Compose/env restored with exact hashes; all three original Medium channels running in new runs.
Registry/settings unchanged; sender execution/media mapping and Redis container preserved. No temporary channel,
receiver, model conversion, dependency change or persistent helper. Runtime helper exited.
The helper's final sender comparison initially compared changing packet counters too, producing an assertion
after successful restoration. It was corrected to compare stable execution/URI/video/mode/state fields;
read-only finalization passed, with no repeated Start/Stop or trial. final.json is authoritative.
Private evidence: baseline-window.json, candidate-window.json, restored-window.json, final.json, summary.csv.