An owner decision can say a LEAN source is still worth re-encoding (measured: x265 crf27 lands at
33-53% of the source video bitrate at SSIM mean >=0.996). --tier cannot express that: it SKIPS any
file whose classification disagrees. --force-tier applies the requested tier instead, with two
guards that stay: copy is refused for a VP9/AV1 source (iOS cannot play the result) and a re-encode
is refused for a file that is already HEVC hvc1 (that is the --overwrite decision).
Owner decision 2026-10-10. Eight items were livelocked in the nvenc tier, burning ~3.3
GPU-hours per pass (initial encode + quality+2 retry) and never converting: they missed the
mean bar by 0.2-1.7 thousandths (0.9626-0.9778) while keeping only 0.20-0.93% of frames
below 0.85 - and per this repo's own comment the FRAME-SHARE test is the one that actually
catches a defect, the mean bar splits a continuum. With SIZE_CEIL=1.0 the mean bar is
unreachable for them by construction.
- library_run.py: POLICY (C:\AI\transcode-run\gate_policy.json) with
* accept - named items are judged by the frame-share test; a mean under the bar is logged,
not enforced. An item that trips the frame-share test is refused even if listed
(0912 洞见, 1.33%, is deliberately absent).
* park - failed quality ROUNDS per item; at PARK_AFTER=2 the item is skipped with a
visible SKIP status instead of being re-encoded. Counters persist in the same file.
- scripts/build_gate_policy.py: builds that file from the run log, taking each key verbatim
from the '--- i/n <relative path>' line (no hand-copying). Result: 7 accepted, 1 refused.
- run/relaunch_nvenc.sh: start the GPU tier ALONE (relaunch_tiers.sh hardcodes both tiers).
- STATE.md: the policy, its rationale and the round counter.
- run/relaunch_x265.sh: start ONLY the x265 tier. run/relaunch_tiers.sh hardcodes
`for t in x265 nvenc`, and the nvenc tier must not start while another job owns the
GPU (the TubeSync 58-file repair batch holds it since 2026-10-09 20:36). x265 is
pinned to the E-cores, so it shares only the RaiDrive mount -- 2 concurrent share
jobs is the documented safe limit.
- The launcher redirects its own banners into the log (under -WindowStyle Hidden,
stdout goes nowhere) and documents the -ArgumentList form: the script path alone.
- STATE.md: LastBootUpTime 2026-10-09 16:51:58 -- both tiers stopped by a REBOOT, not a
bug (x265 404/589, nvenc 308/589); the stale lock pids need no cleanup because
transcode.Lock is staleness-aware. Memory after reboot: 13 GB free / 50.3 of 55.9 GB
committed, but the commit limit fell from 79.6 GB because D: is 92% full.
崇祯传: the 493 MB <live>.new.mp4 the MemoryError left behind was complete. Passed, on a
local copy, structure + FULL DECODE + the picture gate (min 0.9980 / mean 0.9988, 1500
frames, 0 below 0.85) and a hash read-back against the share copy, only then renamed over
the live file (install read-back sha256 5a903ab8a3d1, 493,366,137 B, hevc/hvc1, 3616.8 s).
Saves a 3616 s re-encode: 822,288,651 B h264 -> 493,366,137 B HEVC.
The other 7 were truncated prefixes -> deleted; their live originals are untouched and the
tiers will redo them. 0 *.new.mp4 remain on the share.
Host hit 0 GB physical free / 76.8 of 79.6 GB commit while both tiers ran (pagefile
capped at 32 GB on a 97%-full D:), and the Dokan write of the batch's largest output
raised MemoryError. except OSError does not catch that, so the item was logged
'!! FAIL MemoryError:' with an empty message and the complete 493 MB <live>.new.mp4
stayed on the share; 8 such orphans had accumulated.
- _sha_remote / copy_remote_to_local / copy_local_to_remote: except (OSError, MemoryError)
so a transient host hiccup retries instead of failing the item
- same widening for both partial-file cleanups
- per-item handler: delete <dest>.new.mp4 unconditionally (os.remove + ignore
FileNotFoundError, never gated on os.path.exists - stale metadata on this share)
Verified by injecting MemoryError: the upload path returns False with the partial
deleted, the source read retries then raises a clean IOError, the hash retries twice.
One pass measured 11 attempts rejected purely on the window mean (0.9655-0.9795)
while accepted encodes had worse frame minima (0.33-0.90): the bar was splitting a
continuum, not separating defects. 0718 马斯克原理 failed with min 0.887 and 0.00% of
frames below 0.85. Those files already play (HEVC hvc1 + AAC) and a re-do exists only
to reclaim an old setting's bloat; reaching a 0.98 mean costs more than the source's
own bitrate, which the size ceiling forbids - so the strict bar stranded them with
their bloat while burning an encode every pass.
SSIM_MEAN_MIN_REDO = 0.975 now applies only when the run is re-doing a file that is
genuinely playable (HEVC hvc1 AND aac) from the snapshot original. The frame-share
test (>1% of frames below 0.85) is unchanged and is what catches a real defect.
Verified on ONE file before the tiers were restarted: 0321 随他们去 (rejected last
pass at mean 0.9789) -> ok, mean 0.9786, min 0.5092 with 5 of 1500 frames below 0.85
(fades), 633 MB -> 418 MB installed, live byte count == the encoded output.
The x265/nvenc tiers launched as Hermes background processes were killed
mid-encode at 10:37 when the user's session was closed, so persist_on_release
is not enough here: run/relaunch_tiers.sh starts them orphaned from Hermes
(Start-Process) with a retry loop, which is why they are no longer tracked and
must be stopped by PID only.
STATE.md now carries the progress table (242/589 done, 347 pending: 169 x265 +
174 nvenc + 4 copy), the reason a full `--tier copy` pass must NOT be run (its
only skip test is "already HEVC", which a copy output never satisfies - it
would redo all 193), and the four new weekly episodes handled one file at a
time.
STATE.md carries what the next session needs: the two commands that keep the tiers running, where
the logs/stage/locks/ledger live, the eight bugs this round produced (each with the measurement that
proved it), and the open items. The skill's body now keeps only the load-bearing rules; every
measured case moved to references/pitfalls.md, so the always-loaded part stays readable.
hoelee