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

New issue

Closed

opened 2026-08-02 14:27:21 +02:00 by Claude · 1 comment

Claude commented

2026-08-02 14:27:21 +02:00

Collaborator

BaseItemImageInfos is 0 against upstream's 107, with 325 image files on
disk.

read() computes siblings(entries, &path)
(crates/jellyfin-app/src/scan/run.rs:161, and :306), which returns the files
sharing the item's parent directory. That is right for a file item and wrong
for a folder item: a folder's artwork lives inside it.

For the album music/Sabaton/The Art of War, local_images is handed the
contents of music/Sabaton/ and never sees the Folder.jpg sitting in the
album directory:

music/Sabaton/                     <- what siblings() returns
  01 - Attero Dominatus.flac
  ...
music/Sabaton/The Art of War/      <- where the artwork is
  Folder.jpg
  AlbumArt_{...}_Large.jpg

Found by scanning /mnt/media (285 movies, 289 shows, 74 music artists —
~13 000 media files on a CIFS mount) with both this server and upstream
Jellyfin at the pinned commit, remote metadata and image fetchers disabled on
upstream so both were reading files only. Upstream was given the same mount
path so MD5(UTF-16LE(path)) agrees and rows compare directly.

`BaseItemImageInfos` is **0** against upstream's 107, with 325 image files on disk. `read()` computes `siblings(entries, &path)` (`crates/jellyfin-app/src/scan/run.rs:161`, and `:306`), which returns the files sharing the item's *parent* directory. That is right for a file item and wrong for a folder item: a folder's artwork lives inside it. For the album `music/Sabaton/The Art of War`, `local_images` is handed the contents of `music/Sabaton/` and never sees the `Folder.jpg` sitting in the album directory: music/Sabaton/ <- what siblings() returns 01 - Attero Dominatus.flac ... music/Sabaton/The Art of War/ <- where the artwork is Folder.jpg AlbumArt_{...}_Large.jpg --- Found by scanning `/mnt/media` (285 movies, 289 shows, 74 music artists — ~13 000 media files on a CIFS mount) with both this server and upstream Jellyfin at the pinned commit, remote metadata and image fetchers disabled on upstream so both were reading files only. Upstream was given the same mount path so `MD5(UTF-16LE(path))` agrees and rows compare directly.

Claude added the

scanner

correctness

labels

2026-08-02 14:27:21 +02:00

Claude referenced this issue

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

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

Claude commented

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

Author

Collaborator

Fixed in 0871342 and 06affe9.

An item's artwork and its .nfo were looked for among the files sharing its
directory — right for a file, wrong for a folder, whose own are inside it. The
two read the same directory wherever a film sits alone in a folder, which is why
nothing noticed.

Verified end to end against the real library: the ten pictures upstream reads
off disk are now the ten this reads, with nothing on either side of the diff
(was 0). Worth recording that the issue's "107" was wrong — 97 of upstream's 107
rows are downloaded into its own metadata folder and are out of scope, since
this server never downloads.

Reading a folder's own contents made several rules reachable that had never run,
and review found six wrong: a track has no local artwork at all, each name of a
kind with several is tried prefixed-then-bare before the next name, a landscape
outranks a thumb, a disc picture belongs only to an album or a film and the two
prefer different names, art is a backdrop, and a person prefers folder. Plus
three about documents: a shared movie.nfo describes no film, the fixed name
beats a film's own, and a track reads no document.

What upstream finds that this still does not — further backdrops, extrafanart/,
a season's artwork in the series folder, an episode's metadata/ directory — is
#25.

Fixed in `0871342` and `06affe9`. An item's artwork and its `.nfo` were looked for among the files sharing its directory — right for a file, wrong for a folder, whose own are inside it. The two read the same directory wherever a film sits alone in a folder, which is why nothing noticed. **Verified end to end against the real library: the ten pictures upstream reads off disk are now the ten this reads, with nothing on either side of the diff** (was 0). Worth recording that the issue's "107" was wrong — 97 of upstream's 107 rows are downloaded into its own metadata folder and are out of scope, since this server never downloads. Reading a folder's own contents made several rules reachable that had never run, and review found six wrong: a track has no local artwork at all, each name of a kind with several is tried prefixed-then-bare before the next name, a landscape outranks a thumb, a disc picture belongs only to an album or a film and the two prefer different names, `art` is a backdrop, and a person prefers `folder`. Plus three about documents: a shared `movie.nfo` describes no film, the fixed name beats a film's own, and a track reads no document. What upstream finds that this still does not — further backdrops, `extrafanart/`, a season's artwork in the series folder, an episode's `metadata/` directory — is #25.

Claude closed this issue

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