The --after help names the trigger’s epoch, not a file mtime #142

Merged
dank merged 1 commits from fix/after-epoch-help into main 2026-11-04 12:25:46 -08:00
Owner

--after on both scan drivers documented a journal mtime as the epoch to pass. Measured 2026-11-04, that is the one epoch that cannot work.

  • Jellyfin status|wait --after <mtime> reads the scan task's EndTimeUtc — a scan that finished before the question already passes it, so scannedAfter: true describes a walk that predates your moves. wait refuses such an epoch by name; bare status cannot tell them apart.
  • Plex status --after <mtime> reads section_locations.scanned_at, which PMS stamps when it accepts the request: trigger accepted 19:46:58Z → settled 19:46:58Z, and that same stamp still answered settled at 20:17Z while the walk ran. No epoch survives it — not even the trigger's — so the door is a census, never a waiter.

Text only, no behavior change: the help line and the module docstring now name the trigger's epoch and say why a file mtime lies. The laws themselves live on the vault pages (main 146c28d). ./tests/run.sh: all 841 assertions pass, plus py_compile / bash -n on both scripts.

Deploy note: the planner maps scripts/media-* to the media services, so the next service-scoped deploy of jellyfin/plex syncs this. Nothing running needs it.


cwd: /home/blank/.omp/wt/wt-20261030-163847-6d1fc1f · session: 01a18f2e-18b1-7573-bcd5-ac99636f8bcb
(committed and tested in the worktree /tmp/wt-plexlaw2)

`--after` on both scan drivers documented a **journal mtime** as the epoch to pass. Measured 2026-11-04, that is the one epoch that cannot work. * Jellyfin `status|wait --after <mtime>` reads the scan task's `EndTimeUtc` — a scan that finished before the question already passes it, so `scannedAfter: true` describes a walk that predates your moves. `wait` refuses such an epoch by name; bare `status` cannot tell them apart. * Plex `status --after <mtime>` reads `section_locations.scanned_at`, which PMS stamps when it **accepts** the request: trigger accepted `19:46:58Z` → `settled` `19:46:58Z`, and that same stamp still answered `settled` at `20:17Z` while the walk ran. No epoch survives it — not even the trigger's — so the door is a census, never a waiter. Text only, no behavior change: the help line and the module docstring now name the trigger's epoch and say why a file mtime lies. The laws themselves live on the vault pages (`main` 146c28d). `./tests/run.sh`: all 841 assertions pass, plus `py_compile` / `bash -n` on both scripts. Deploy note: the planner maps `scripts/media-*` to the media services, so the next service-scoped deploy of jellyfin/plex syncs this. Nothing running needs it. --- cwd: /home/blank/.omp/wt/wt-20261030-163847-6d1fc1f · session: 01a18f2e-18b1-7573-bcd5-ac99636f8bcb (committed and tested in the worktree `/tmp/wt-plexlaw2`)
dank added 1 commit 2026-11-04 12:25:06 -08:00
Both drivers' help text recommended `--after "$(stat -c %Y <journal>)"`. Measured
2026-11-04 that epoch is answered by whatever scan finished before the question was
asked: on Jellyfin it reads an earlier task's EndTimeUtc, and the Plex door cannot be
a waiter at all, since PMS stamps section_locations.scanned_at when it accepts the
request. The laws are on the vault pages (main 146c28d); this puts the warning at
point of use, in the text an agent reads before calling the door.
dank merged commit 70aa40a24a into main 2026-11-04 12:25:46 -08:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dank/serverAppConfigs#142