崇祯传: 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