docs(jellyfin): the recursive Movie list is not proof an item is indexed #126

Merged
dank merged 1 commits from docs/jellyfin-verification-read into main 2026-11-02 19:14:33 -08:00
Owner

Verification, not bookkeeping: the read an agent reaches for when asking "did that refresh index what I moved" gives the wrong answer, and I walked into it tonight.

Measured 2026-11-03

Read Answer
GET /Items?IncludeItemTypes=Movie&Recursive=true 2,101 items
GET /Items?ParentId=<Movies ItemId> 2,548 children — one per folder on disk

Eight folders the recursive list does not return — the three Mobile Suit Gundam 00 Special Edition films and the five Sailor Moon Memorial films — each answer as Type: Movie through SearchTerm and appear in the folder listing, at the paths the journal moved them to. So the shortfall is grouping, not missing media.

The consequence

Verifying a move against the recursive type list produces a false "not indexed" verdict. The next action that verdict invites is another full-library scan, which costs CPU on a host serving users and changes nothing. The page now states which read proves an item, and demotes the recursive count to a trend line.

Diff

One law paragraph in serverAppConfigs-docs/Dankserver/Jellyfin.md, placed after the coverage check (the two reads an agent runs in the same sitting). No script, unit, or config touched.

./tests/run.sh — 822 seams, all pass. The vault's own link-integrity and OKF seams cover the edited page.

The procedural copy of this law lives in the operator's managed skill jellyfin-index-completeness-census, which now links here as the owner; the DB-side sibling trap (BaseItems.Type stores CLR class names, so Type='Movie' counts zero) is recorded there rather than duplicating this page.


cwd: /home/blank/.omp/wt/wt-20261030-163847-6d1fc1f · session: 01a18f2e-18b1-7573-bcd5-ac99636f8bcb

Verification, not bookkeeping: the read an agent reaches for when asking "did that refresh index what I moved" gives the wrong answer, and I walked into it tonight. ## Measured 2026-11-03 | Read | Answer | |---|---| | `GET /Items?IncludeItemTypes=Movie&Recursive=true` | 2,101 items | | `GET /Items?ParentId=<Movies ItemId>` | 2,548 children — one per folder on disk | Eight folders the recursive list does not return — the three *Mobile Suit Gundam 00 Special Edition* films and the five *Sailor Moon Memorial* films — each answer as `Type: Movie` through `SearchTerm` and appear in the folder listing, at the paths the journal moved them to. So the shortfall is **grouping, not missing media**. ## The consequence Verifying a move against the recursive type list produces a false "not indexed" verdict. The next action that verdict invites is another full-library scan, which costs CPU on a host serving users and changes nothing. The page now states which read proves an item, and demotes the recursive count to a trend line. ## Diff One law paragraph in `serverAppConfigs-docs/Dankserver/Jellyfin.md`, placed after the coverage check (the two reads an agent runs in the same sitting). No script, unit, or config touched. `./tests/run.sh` — **822 seams, all pass**. The vault's own link-integrity and OKF seams cover the edited page. The procedural copy of this law lives in the operator's managed skill `jellyfin-index-completeness-census`, which now links here as the owner; the DB-side sibling trap (`BaseItems.Type` stores CLR class names, so `Type='Movie'` counts zero) is recorded there rather than duplicating this page. --- cwd: /home/blank/.omp/wt/wt-20261030-163847-6d1fc1f · session: 01a18f2e-18b1-7573-bcd5-ac99636f8bcb
dank added 1 commit 2026-11-02 18:52:24 -08:00
dank merged commit f3a6b4f715 into main 2026-11-02 19:14:33 -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#126