Only one backdrop is taken, and three artwork sources are unread #25

New issue

Closed

opened 2026-08-02 17:18:02 +02:00 by Claude · 1 comment

Claude commented

2026-08-02 17:18:02 +02:00

Collaborator

An item may carry several backdrops and takes only one here, and three
sources of artwork upstream reads are not read at all.

LocalImageProvider.PopulateBackdrops is not a first-match-wins list — Backdrop
is the one type ItemImageProvider does not collapse to a single image, so
upstream keeps every match:

<name>-fanart, then fanart and fanart-1 .. fanart-20
background and background-1 .. background-20
art and art-1 .. art-20
everything inside an extrafanart/ directory
backdrop and backdrop1 .. backdrop20

Ours takes the first of fanart, background, art, backdrop and stops, so
the first backdrop agrees with upstream and any further one is missing.
extrafanart/ also needs accompanying to stop filtering directories out.

Two more sources, neither ported:

PopulateSeasonImagesFromSeriesFolder gives a season its primary, backdrop,
banner and thumbnail from season01-poster, season01-fanart and the rest
sitting in the series folder. A season now reads its own folder and
nothing above it.
EpisodeLocalImageProvider reads a metadata/ subdirectory of the episode's
folder as well as the folder itself.

Found while reviewing #6, which fixed the folder lookup and the rules it made
reachable. None of this is a wrong answer — it is artwork upstream finds that
this does not.

An item may carry several backdrops and takes only one here, and three sources of artwork upstream reads are not read at all. `LocalImageProvider.PopulateBackdrops` is not a first-match-wins list — `Backdrop` is the one type `ItemImageProvider` does not collapse to a single image, so upstream keeps every match: - `<name>-fanart`, then `fanart` and `fanart-1` .. `fanart-20` - `background` and `background-1` .. `background-20` - `art` and `art-1` .. `art-20` - everything inside an `extrafanart/` directory - `backdrop` and `backdrop1` .. `backdrop20` Ours takes the first of `fanart`, `background`, `art`, `backdrop` and stops, so the *first* backdrop agrees with upstream and any further one is missing. `extrafanart/` also needs `accompanying` to stop filtering directories out. Two more sources, neither ported: - `PopulateSeasonImagesFromSeriesFolder` gives a season its primary, backdrop, banner and thumbnail from `season01-poster`, `season01-fanart` and the rest sitting in the **series** folder. A season now reads its own folder and nothing above it. - `EpisodeLocalImageProvider` reads a `metadata/` subdirectory of the episode's folder as well as the folder itself. Found while reviewing #6, which fixed the folder lookup and the rules it made reachable. None of this is a wrong answer — it is artwork upstream finds that this does not.

Claude added the

scanner

correctness

labels

2026-08-02 17:18:02 +02:00

Claude referenced this issue

2026-08-02 17:18:19 +02:00

Folder artwork is never found — siblings() returns the parent's contents #6

Claude referenced this issue

2026-08-03 13:50:25 +02:00

A sample file beside a film is filed as a film #37

Claude commented

2026-08-03 14:00:52 +02:00

Author

Collaborator

Fixed in the merge of fix/25-artwork-sources.

What changed

A backdrop is the one picture an item may carry several of, so every one of
them is taken. Each family is read whole — fanart and fanart-1 upward,
then background, then art, then whatever an extrafanart directory holds,
then backdrop and backdrop1 upward — numbered to twenty and giving up once
three are missing, counted over the run rather than three in a row, which is
upstream's own counter.

The two sources nothing read:

A season takes what the series folder above it names for it, built from what
the season is called and what it is numbered — so Specials answers to both
specials-poster and season-specials-poster, and Season 1 to season1-
and season01-. It answers under the name the library resolved to and not
under a title its own document gave it: upstream looks for an item's pictures
before it reads a document beside it.
An episode answers to a metadata directory beside it as well as to the
folder holding it.

Everything but a backdrop is still one picture. That had to come with this:
a season now has two rules naming its primary, and upstream keeps the first
and drops the rest.

What this dragged in

Creating an extrafanart directory — which is what this feature asks a user to
do — cost a film the name of its folder and filed a row for the directory
itself, because nothing here ignored it. The directories upstream never
resolves media out of are now ignored at resolution: metadata, extrafanart,
extrathumbs, subs, .actors, the recycle bins, and the rest of
IgnorePatterns.cs's directory block. The artwork rules still read the two
they need, reaching them outside the resolver as upstream does.

That turned up a test which had encoded the unignored behaviour: a film sharing
its folder with Subs/ was taking its file's name where upstream gives it the
folder's.

Verified against

Upstream's source rather than a diff: no library here carries local artwork
beside its media — the reference fixture has none, and the real one's backdrops
were fetched into the metadata directory rather than found on disk. The rules
are pinned by tests in crates/jellyfin-app/src/scan/images.rs and
crates/jellyfin-app/tests/scan_images.rs, each written from
LocalImageProvider.cs, EpisodeLocalImageProvider.cs and
ItemImageProvider.cs.

Left for later

#37 — the files upstream ignores and this does not: sample.*, minta.*,
small.jpg, albumart.jpg, and hidden directories as a class.

Fixed in the merge of `fix/25-artwork-sources`. ## What changed A backdrop is the one picture an item may carry several of, so every one of them is taken. Each family is read whole — `fanart` and `fanart-1` upward, then `background`, then `art`, then whatever an `extrafanart` directory holds, then `backdrop` and `backdrop1` upward — numbered to twenty and giving up once three are missing, counted over the run rather than three in a row, which is upstream's own counter. The two sources nothing read: - A season takes what the series folder above it names for it, built from what the season is called and what it is numbered — so `Specials` answers to both `specials-poster` and `season-specials-poster`, and `Season 1` to `season1-` and `season01-`. It answers under the name the library resolved to and not under a title its own document gave it: upstream looks for an item's pictures before it reads a document beside it. - An episode answers to a `metadata` directory beside it as well as to the folder holding it. Everything but a backdrop is still one picture. That had to come with this: a season now has two rules naming its primary, and upstream keeps the first and drops the rest. ## What this dragged in Creating an `extrafanart` directory — which is what this feature asks a user to do — cost a film the name of its folder and filed a row for the directory itself, because nothing here ignored it. The directories upstream never resolves media out of are now ignored at resolution: `metadata`, `extrafanart`, `extrathumbs`, `subs`, `.actors`, the recycle bins, and the rest of `IgnorePatterns.cs`'s directory block. The artwork rules still read the two they need, reaching them outside the resolver as upstream does. That turned up a test which had encoded the unignored behaviour: a film sharing its folder with `Subs/` was taking its file's name where upstream gives it the folder's. ## Verified against Upstream's source rather than a diff: no library here carries local artwork beside its media — the reference fixture has none, and the real one's backdrops were fetched into the metadata directory rather than found on disk. The rules are pinned by tests in `crates/jellyfin-app/src/scan/images.rs` and `crates/jellyfin-app/tests/scan_images.rs`, each written from `LocalImageProvider.cs`, `EpisodeLocalImageProvider.cs` and `ItemImageProvider.cs`. ## Left for later - #37 — the files upstream ignores and this does not: `sample.*`, `minta.*`, `small.jpg`, `albumart.jpg`, and hidden directories as a class.

Claude closed this issue

2026-08-03 14:00:52 +02:00