One vault file, serverAppConfigs-docs/Dankserver/Jellyfin.md, carrying three corrections and one new law. No code, no config, no deploy.
Why each line
The per-library switches are under LibraryOptions, not top-level DTO keys. GET /Library/VirtualFolders returns Name, CollectionType, Locations, ItemId, PrimaryImageItemId, RefreshStatus, LibraryOptions. Reading EnableInternetProviders
off the folder itself answers None for all four libraries — which reads exactly like an
unconfigured library. Hit this today while re-checking posture; the page named the camelCase
trap but stopped one level short of it. Cross-checked every value against each library's config/root/default/<Library>/options.xml.
A pinned art pass is not a provider census — main's "zero downloads" conclusion is falsified.
The law added today concluded, from a TMDb-pinned RemoteImages/Download campaign over Shows
that classified everything and downloaded nothing, that identification was the only lever left.
The same door, queried with no Providers= filter, answered for 16 seasons the same day —
every offer from TheTVDB, which the pinned form never asks. All 16 are dressed now: seasons
with art went 2,674 → 2,690, series 727/733, and a poster serves 200 image/jpeg.
The surviving half of that conclusion is kept, with a fresh number: the artless remainder is 86 items (80 seasons, 6 series) — 61 carry no provider id at all (the unnamed long tail: 3a BBW - Series (2010-11), History Of Africa With Zeinab Badawi, (Warhammer TV)-shaped
dirs) and 25 hold an id and draw no offer from any provider. No image retry moves either.
/Items?Ids= needs no UserId; /Items/{id} does.
The page lumped both routes together. The list route answers token-authenticated without UserId; it is /Items/{id} that returns 400 Error processing request, and that bites
hardest as a verification read immediately after a write that succeeded — which is how
an art loop reports a crash over a completed download. Verify writes through the list route.
Evidence
Fill run: gap probed=101 ok=15 fail=0 no_offer=86 (plus one item from the first attempt = 16 landed), log /home/dank/campaign/tvshows/art_fill2.log.
Census after the fill: seasons 2,690/2,779 with ImageTags.Primary; series 727/733.
POST /Items/{id}/RemoteImages/Download → 204; GET /Items/{id} → 400; GET /Items/{id}/Images/Primary → 200 image/jpeg, 119 KB.
Posture from options.xml on disk: Movies true, Shows true, Music false, Collections element absent.
./tests/run.sh → ALL TESTS PASSED (822 seams).
Notes
Branch also carries two commits already landed by other PRs; the diff against main is this one file only. Merged origin/main in (no rebase) — two conflicts, both resolved toward main where the parallel PRs already own the fact (Shows flip, Audiobookshelf residual), so nothing here restates them.
## What
One vault file, `serverAppConfigs-docs/Dankserver/Jellyfin.md`, carrying three corrections and one new law. No code, no config, no deploy.
## Why each line
**The per-library switches are under `LibraryOptions`, not top-level DTO keys.**
`GET /Library/VirtualFolders` returns `Name`, `CollectionType`, `Locations`, `ItemId`,
`PrimaryImageItemId`, `RefreshStatus`, `LibraryOptions`. Reading `EnableInternetProviders`
off the folder itself answers `None` for all four libraries — which reads exactly like an
unconfigured library. Hit this today while re-checking posture; the page named the camelCase
trap but stopped one level short of it. Cross-checked every value against each library's
`config/root/default/<Library>/options.xml`.
**A pinned art pass is not a provider census — main's "zero downloads" conclusion is falsified.**
The law added today concluded, from a TMDb-pinned `RemoteImages/Download` campaign over `Shows`
that classified everything and downloaded nothing, that identification was the only lever left.
The same door, queried with no `Providers=` filter, answered for **16 seasons the same day** —
every offer from `TheTVDB`, which the pinned form never asks. All 16 are dressed now: seasons
with art went **2,674 → 2,690**, series 727/733, and a poster serves `200 image/jpeg`.
The surviving half of that conclusion is kept, with a fresh number: the artless remainder is
**86 items** (80 seasons, 6 series) — **61** carry no provider id at all (the unnamed long tail:
`3a BBW - Series (2010-11)`, `History Of Africa With Zeinab Badawi`, `(Warhammer TV)`-shaped
dirs) and **25** hold an id and draw no offer from any provider. No image retry moves either.
**`/Items?Ids=` needs no `UserId`; `/Items/{id}` does.**
The page lumped both routes together. The list route answers token-authenticated without
`UserId`; it is `/Items/{id}` that returns `400 Error processing request`, and that bites
hardest as a *verification* read immediately after a write that **succeeded** — which is how
an art loop reports a crash over a completed download. Verify writes through the list route.
## Evidence
- Fill run: `gap probed=101 ok=15 fail=0 no_offer=86` (plus one item from the first attempt = 16 landed), log `/home/dank/campaign/tvshows/art_fill2.log`.
- Census after the fill: seasons 2,690/2,779 with `ImageTags.Primary`; series 727/733.
- `POST /Items/{id}/RemoteImages/Download` → `204`; `GET /Items/{id}` → `400`; `GET /Items/{id}/Images/Primary` → `200 image/jpeg`, 119 KB.
- Posture from `options.xml` on disk: `Movies` true, `Shows` true, `Music` false, `Collections` element absent.
- `./tests/run.sh` → ALL TESTS PASSED (822 seams).
## Notes
Branch also carries two commits already landed by other PRs; the diff against `main` is this one file only. Merged `origin/main` in (no rebase) — two conflicts, both resolved toward `main` where the parallel PRs already own the fact (`Shows` flip, Audiobookshelf residual), so nothing here restates them.
---
cwd: /home/blank/.omp/wt/wt-20261030-163847-6d1fc1f · session: 01a18f2e-18b1-7573-bcd5-ac99636f8bcb
The page sent the next agent to POST /Items/{id}/Refresh?Recursive=true per
library to make a new folder visible. Measured against a Shows library that had
never been identified: that route answers 204 and queues nothing — item census
byte-identical, ScheduledTasks idle, journal silent, and still a silent 204 after
a service restart. The door that works is POST /Library/Refresh, and the progress
read is ScheduledTasks -> Scan Media Library -> CurrentProgressPercentage.
RefreshStatus on the VirtualFolders record stays Idle through a real scan, so it
is not a progress read at all; a 204 cannot distinguish accepted-and-discarded
from accepted-and-queued, so the acceptance read is the journal naming folders.
Also recorded the art door's wire shape, because guessing it reads as a server
bug: the list response carries the address in Url (there is no ImageUrl), the
Download POST takes camelCase type/imageUrl and answers 204, and PascalCase or an
empty imageUrl answers 500. RemoteImages is empty for items with no ProviderIds,
so art coverage is capped by identification, not by the image door.
The first full scan logged "Invalid data found when processing input" per file and
carried on. That line is about the file: the scanner skips it, so the book never
appears in the library at all. Census of the 43 refused files: 38 were 0 bytes, 3
held WAV bytes behind a .mp3 name, 2 were unreadable. The check to run first is a
byte count, not a server investigation.
Full suite: 818 tests, exit 0.
- the per-library switches are under LibraryOptions, not top-level DTO keys
- Shows was flipped on 2026-11-02; Music is the only silent file index left
- never pin Providers= on a TV art loop: the TVDB-only offers disappear
- /Items?Ids= needs no UserId where /Items/{id} does, so verify writes there
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What
One vault file,
serverAppConfigs-docs/Dankserver/Jellyfin.md, carrying three corrections and one new law. No code, no config, no deploy.Why each line
The per-library switches are under
LibraryOptions, not top-level DTO keys.GET /Library/VirtualFoldersreturnsName,CollectionType,Locations,ItemId,PrimaryImageItemId,RefreshStatus,LibraryOptions. ReadingEnableInternetProvidersoff the folder itself answers
Nonefor all four libraries — which reads exactly like anunconfigured library. Hit this today while re-checking posture; the page named the camelCase
trap but stopped one level short of it. Cross-checked every value against each library's
config/root/default/<Library>/options.xml.A pinned art pass is not a provider census — main's "zero downloads" conclusion is falsified.
The law added today concluded, from a TMDb-pinned
RemoteImages/Downloadcampaign overShowsthat classified everything and downloaded nothing, that identification was the only lever left.
The same door, queried with no
Providers=filter, answered for 16 seasons the same day —every offer from
TheTVDB, which the pinned form never asks. All 16 are dressed now: seasonswith art went 2,674 → 2,690, series 727/733, and a poster serves
200 image/jpeg.The surviving half of that conclusion is kept, with a fresh number: the artless remainder is
86 items (80 seasons, 6 series) — 61 carry no provider id at all (the unnamed long tail:
3a BBW - Series (2010-11),History Of Africa With Zeinab Badawi,(Warhammer TV)-shapeddirs) and 25 hold an id and draw no offer from any provider. No image retry moves either.
/Items?Ids=needs noUserId;/Items/{id}does.The page lumped both routes together. The list route answers token-authenticated without
UserId; it is/Items/{id}that returns400 Error processing request, and that biteshardest as a verification read immediately after a write that succeeded — which is how
an art loop reports a crash over a completed download. Verify writes through the list route.
Evidence
gap probed=101 ok=15 fail=0 no_offer=86(plus one item from the first attempt = 16 landed), log/home/dank/campaign/tvshows/art_fill2.log.ImageTags.Primary; series 727/733.POST /Items/{id}/RemoteImages/Download→204;GET /Items/{id}→400;GET /Items/{id}/Images/Primary→200 image/jpeg, 119 KB.options.xmlon disk:Moviestrue,Showstrue,Musicfalse,Collectionselement absent../tests/run.sh→ ALL TESTS PASSED (822 seams).Notes
Branch also carries two commits already landed by other PRs; the diff against
mainis this one file only. Mergedorigin/mainin (no rebase) — two conflicts, both resolved towardmainwhere the parallel PRs already own the fact (Showsflip, Audiobookshelf residual), so nothing here restates them.cwd: /home/blank/.omp/wt/wt-20261030-163847-6d1fc1f · session: 01a18f2e-18b1-7573-bcd5-ac99636f8bcb
The page sent the next agent to POST /Items/{id}/Refresh?Recursive=true per library to make a new folder visible. Measured against a Shows library that had never been identified: that route answers 204 and queues nothing — item census byte-identical, ScheduledTasks idle, journal silent, and still a silent 204 after a service restart. The door that works is POST /Library/Refresh, and the progress read is ScheduledTasks -> Scan Media Library -> CurrentProgressPercentage. RefreshStatus on the VirtualFolders record stays Idle through a real scan, so it is not a progress read at all; a 204 cannot distinguish accepted-and-discarded from accepted-and-queued, so the acceptance read is the journal naming folders. Also recorded the art door's wire shape, because guessing it reads as a server bug: the list response carries the address in Url (there is no ImageUrl), the Download POST takes camelCase type/imageUrl and answers 204, and PascalCase or an empty imageUrl answers 500. RemoteImages is empty for items with no ProviderIds, so art coverage is capped by identification, not by the image door.- the per-library switches are under LibraryOptions, not top-level DTO keys - Shows was flipped on 2026-11-02; Music is the only silent file index left - never pin Providers= on a TV art loop: the TVDB-only offers disappear - /Items?Ids= needs no UserId where /Items/{id} does, so verify writes there