From 4fb118b2db32f269c5aeb217644dc5e80640c885 Mon Sep 17 00:00:00 2001 From: Peter Stone Date: Tue, 29 Sep 2026 10:41:33 -1000 Subject: Protect a show's Tier 3 pending episode from retention reclaim Peter's call (option 1 of the three in docs/detection-findings.md): exempt an episode retention would otherwise reclaim while it is a show's pending comparison basis, rather than extending the grace period or accepting the gap. RetentionSweeper gains a pendingEpisodeIds seam (suspend () -> Set, defaulting to empty) and filters its reclaim candidates against it before the grace-period policy ever sees them -- every existing caller and test was unaffected by the default. RetentionWorker wires the real thing: the union of two new, narrow DAO queries -- ShowFingerprintDao.getAllPendingEpisodeIds() (intro/outro) and MidrollDao.getAllMidrollPendingEpisodeIds() (midroll, reading SubscriptionEntity.midrollPendingEpisodeId). Applied to both fingerprinting mechanisms, not just the one that got diagnosed: MidrollUpdater's discovery has the identical rolling-pending- episode shape and would race retention the same way for a fast show, just silently, with no frozen row to reveal it. Not yet re-verified on a device -- the next live test is two Up First downloads close enough together to actually compare, confirming pendingEpisodeId advances to a real second episode instead of restarting. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01Sj3CoWEedM56bebByKgNxA --- CLAUDE.md | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) (limited to 'CLAUDE.md') diff --git a/CLAUDE.md b/CLAUDE.md index 76ed20d..8121bfe 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -194,15 +194,21 @@ by default and correct; it is simply waiting for a publisher who marks breaks. - **Auto-downloads are not retried.** A rule's download that fails is left FAILED rather than requeued: retrying forever against a 404 would burn the battery, and the failed row is visible in the episode list. Retry is the manual Download button. -- **Tier 3 has never confirmed a real intro, outro or midroll.** The pipeline runs on hardware - and the worker succeeds, but three consecutive Up First downloads produced no candidate at - either end. Two live hypotheses -- an 8-second reference window against a ~6-second sting, - and pre-roll ads moving the intro to a different offset in every file. **See - `docs/detection-findings.md`**, which is the brief for the desktop session that settles it: - what is already known, the experiments in order, and what not to touch. Do not tune - `DEFAULT_REFERENCE_SECONDS`, `MIN_SCORE` or `CONFIRM_THRESHOLD` from the app -- the app - cannot show you what a change costs in false positives, and the threshold is the whole - safety mechanism. +- **Tier 3 had never confirmed a real intro, outro or midroll, and root cause is now found and + fixed.** Not the correlation algorithm -- a real production-algorithm simulation against real + Up First audio confirmed cleanly at the app's actual defaults before any of this. The real + cause: `RetentionPolicy`'s one-day grace period routinely reclaimed a show's pending episode's + file before the next download arrived to compare it against, for a fast, promptly-listened-to + show like Up First -- so the detector kept discarding its only candidate and restarting instead + of ever comparing two episodes. Confirmed live on the phone (a fresh download's + `FingerprintWorker` run replaced the stale pending episode instead of advancing toward a + comparison). Fixed by protecting a show's pending episode from reclaim, for both intro/outro + and midroll -- `RetentionSweeper` now takes a `pendingEpisodeIds` seam and + `RetentionWorker` supplies the union of both mechanisms' pending ids. **Not yet re-verified on + a device.** Full history in `docs/detection-findings.md`. Do not tune + `DEFAULT_REFERENCE_SECONDS`, `MIN_SCORE` or `CONFIRM_THRESHOLD` from the app -- they were never + the problem, the app cannot show you what a change costs in false positives, and the threshold + is the whole safety mechanism. - **Android Auto is verified in a real car**, as of 2026-09-28. It appears, and connects. The notification Peter saw on first connect was Android Auto's own new-media-app announcement, -- cgit v1.2.3