Studio images are in scope after all, and StudiosImageProvider is not written #157

New issue

Closed

opened 2026-08-16 21:44:50 +02:00 by Claude · 1 comment

Claude commented

2026-08-16 21:44:50 +02:00

Collaborator

StudiosImageProvider is the last in-box provider nothing here answers for.

#105 carried one correction of its own, and landing it opened this: MILESTONES.md
(M11) used to rule studio images out as a plugin, and they are not one.
MediaBrowser.Providers/Plugins/StudioImages/StudiosImageProvider.cs is compiled
into the server like the rest of that directory, so the fixture's four studio
thumbnails are something a stock upstream produces and a stock port has to.

It is unlike every other provider on that list in one way worth knowing before
starting: what it fetches from is a remote repository of logos — a flat list of
names in a git repository, matched against the studio's name — rather than a
metadata database keyed by an id. There is no search, no rate limit and no API
key.

Where to start

MediaBrowser.Providers/Plugins/StudioImages/StudiosImageProvider.cs. The
provider fetches a manifest of available names once and then asks for the two
pictures a studio can have, so what is recorded in the cassette is that manifest
plus one request per studio the fixture holds.

The consumer already exists: a studio is a by-name row, and
crates/jellyfin-app/src/scan/by_name.rs stands one up for every studio a film
names.

How to know it is done

The four studio thumbnails in the fixture are ours rather than a difference the
harness reports, compared on bytes the way every other picture in this project
is — and crates/jellyfin-harness/README.md's ignore list loses whatever entry
covers them.

House rules

CLAUDE.md is the short version and these are the parts that bite: tests run
under cargo nextest; upstream's source is the checkout in upstream/ at the
pin (v12.0-rc5, 6d501ba4) and not the clone beside the repository;
generated files are regenerated rather than edited; a comment says what the code
does, not how it got there; and Dn references stay out of code and comments.

The reference pair is cargo xtask reference up, a run is
cargo run -p jellyfin-harness -- replay ..., and every ignore entry carries a
reason and an expiry.

`StudiosImageProvider` is the last in-box provider nothing here answers for. #105 carried one correction of its own, and landing it opened this: `MILESTONES.md` (M11) used to rule studio images out as a plugin, and they are not one. `MediaBrowser.Providers/Plugins/StudioImages/StudiosImageProvider.cs` is compiled into the server like the rest of that directory, so the fixture's four studio thumbnails are something a stock upstream produces and a stock port has to. It is unlike every other provider on that list in one way worth knowing before starting: what it fetches from is a remote repository of logos — a flat list of names in a git repository, matched against the studio's name — rather than a metadata database keyed by an id. There is no search, no rate limit and no API key. ## Where to start `MediaBrowser.Providers/Plugins/StudioImages/StudiosImageProvider.cs`. The provider fetches a manifest of available names once and then asks for the two pictures a studio can have, so what is recorded in the cassette is that manifest plus one request per studio the fixture holds. The consumer already exists: a studio is a by-name row, and `crates/jellyfin-app/src/scan/by_name.rs` stands one up for every studio a film names. ## How to know it is done The four studio thumbnails in the fixture are ours rather than a difference the harness reports, compared on bytes the way every other picture in this project is — and `crates/jellyfin-harness/README.md`'s ignore list loses whatever entry covers them. ### House rules `CLAUDE.md` is the short version and these are the parts that bite: tests run under `cargo nextest`; upstream's source is the checkout in `upstream/` **at the pin** (`v12.0-rc5`, `6d501ba4`) and not the clone beside the repository; generated files are regenerated rather than edited; a comment says what the code does, not how it got there; and `Dn` references stay out of code and comments. The reference pair is `cargo xtask reference up`, a run is `cargo run -p jellyfin-harness -- replay ...`, and every ignore entry carries a reason and an expiry.

Claude added the

providers

labels

2026-08-20 17:31:12 +02:00

Claude commented

2026-08-21 08:21:44 +02:00

Author

Collaborator

Closed by 1efcc2a.

crates/ephyra-app/src/metadata/artwork.rs is the port of StudiosImageProvider: it fetches {repository}/thumbs.txt once per pass, folds a studio's name past the six characters a directory is not named with, and offers {repository}/images/{name}/thumb.jpg as a Thumb for a name the list holds. The list is not valid UTF-8 and is decoded lossily, which is what upstream's StreamReader does with it. studio_artwork_repository in [metadata] points it elsewhere; empty asks the repository upstream's own plugin points at.

It runs where upstream's StudiosPostScanTask runs it — over the studio rows the pass created and no others, which is StudiosValidator's own !existingStudioIds.Contains(item.Id). So a studio the repository holds nothing for is asked about once rather than on every scan. The picture is written to the studio's own directory as landscape.jpg; keeps_its_pictures now files a Studio where it files a Person rather than in the shard an item's pictures hash to.

The fixture. The enriched library names fifteen studios and upstream saved a logo for ten of them. The pair now carries all fifteen — enriched.json grew a studios key, and the recording grew the list plus the ten pictures, laid over with the very files upstream downloaded. crates/ephyra-app/tests/studios.rs holds the port to all of it: which ten are offered a logo and which five are not, the bytes of each of the ten, that the list is asked for once however many studios there are, and where the file lands.

One thing the issue asked for that is not there. No harness run exercises this either, and none can as things stand: the default fixture both servers replay against registers its libraries with every fetcher off, so no film in it is filed under a studio and /Studios reports nothing on both sides. There was no ignore-list entry covering studio pictures to retire — the only mention was a line in crates/ephyra-harness/README.md naming them among the known differences, and that line now says what is true instead. A pair run over studio logos wants a library provisioned with fetchers on, which is the same thing #148 and #117 need.

Closed by `1efcc2a`. `crates/ephyra-app/src/metadata/artwork.rs` is the port of `StudiosImageProvider`: it fetches `{repository}/thumbs.txt` once per pass, folds a studio's name past the six characters a directory is not named with, and offers `{repository}/images/{name}/thumb.jpg` as a `Thumb` for a name the list holds. The list is not valid UTF-8 and is decoded lossily, which is what upstream's `StreamReader` does with it. `studio_artwork_repository` in `[metadata]` points it elsewhere; empty asks the repository upstream's own plugin points at. It runs where upstream's `StudiosPostScanTask` runs it — over the studio rows the pass created and no others, which is `StudiosValidator`'s own `!existingStudioIds.Contains(item.Id)`. So a studio the repository holds nothing for is asked about once rather than on every scan. The picture is written to the studio's own directory as `landscape.jpg`; `keeps_its_pictures` now files a `Studio` where it files a `Person` rather than in the shard an item's pictures hash to. **The fixture.** The enriched library names fifteen studios and upstream saved a logo for ten of them. The pair now carries all fifteen — `enriched.json` grew a `studios` key, and the recording grew the list plus the ten pictures, laid over with the very files upstream downloaded. `crates/ephyra-app/tests/studios.rs` holds the port to all of it: which ten are offered a logo and which five are not, the bytes of each of the ten, that the list is asked for once however many studios there are, and where the file lands. **One thing the issue asked for that is not there.** No harness run exercises this either, and none can as things stand: the `default` fixture both servers replay against registers its libraries with every fetcher off, so no film in it is filed under a studio and `/Studios` reports nothing on both sides. There was no ignore-list entry covering studio pictures to retire — the only mention was a line in `crates/ephyra-harness/README.md` naming them among the known differences, and that line now says what is true instead. A pair run over studio logos wants a library provisioned with fetchers on, which is the same thing #148 and #117 need.

Claude closed this issue

2026-08-21 08:21:44 +02:00