ItemValues and ItemValuesMap are never written, so the by-name endpoints are always empty #9

New issue

Closed

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

Claude commented

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

Collaborator

Nothing in jellyfin-app/scan or jellyfin-db/src/scan.rs writes ItemValues
or ItemValuesMap. The only references in the tree are the read queries in
jellyfin-db/src/query.rs and jellyfin-db/src/items.rs.

ItemValues 0 against upstream's 515 (185 Artist, 99 AlbumArtist, 232 Genre);
ItemValuesMap 0 against 20 280.

So /Genres, /Studios, /Persons, /MusicGenres and /Artists all answer
200 with zero items on any library this server scanned itself. They return
data only against a snapshot upstream populated.

74 MusicArtist rows exist as items and /Artists still answers empty: the
route reads ItemValues, not BaseItems by type.

Upstream fills all of it from container tags with every remote provider
disabled, so none of it depends on the internet.

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.

Nothing in `jellyfin-app/scan` or `jellyfin-db/src/scan.rs` writes `ItemValues` or `ItemValuesMap`. The only references in the tree are the read queries in `jellyfin-db/src/query.rs` and `jellyfin-db/src/items.rs`. `ItemValues` 0 against upstream's 515 (185 Artist, 99 AlbumArtist, 232 Genre); `ItemValuesMap` 0 against 20 280. So `/Genres`, `/Studios`, `/Persons`, `/MusicGenres` and `/Artists` all answer `200` with zero items on any library this server scanned itself. They return data only against a snapshot upstream populated. 74 `MusicArtist` rows exist as items and `/Artists` still answers empty: the route reads `ItemValues`, not `BaseItems` by type. Upstream fills all of it from container tags with every remote provider disabled, so none of it depends on the internet. --- 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:22 +02:00

Claude referenced this issue

2026-08-02 18:22:10 +02:00

A track's tags are split where upstream does not split them #27

Claude referenced this issue

2026-08-02 18:22:10 +02:00

A database scanned by an older build keeps what that build did not write #28

Claude commented

2026-08-02 18:22:28 +02:00

Author

Collaborator

Fixed in f2cb2e4 and 6d185f2.

An item is now listed under each of its artists, album artists and genres — one row
per value across the library, one link per item that names it, blanks skipped, and a
value nothing names any more goes with the last item that named it.

Against the real library: 429 values written where upstream has 515, 383 identical.
The 46 that differ are not this write path — they are a faithful reflection of
BaseItems.Genres/Artists, which diverge because upstream reads a track's tags
through ATL rather than the ffprobe normalizer and splits them far less. That is #27.
The 86 upstream has that we do not are the album and artist rows summarised from
tracks, which is #24.

Review found the write transcribed the value types into a new enum where
jellyfin-core already carries the generated one — and the same crate imports it to
read this table. Fixed, along with the artist gate (now agreeing with the artist
columns) and the link delete (scoped to the kinds actually rewritten).

ItemValueId is now on the database ignore list: upstream draws a fresh GUID per
value, ours is derived so a rescan writes the row it wrote before, and nothing reads it
across databases.

One thing this does not do: backfill a database scanned by an older build. Every
item is unchanged, so nothing is rewritten and the values never appear. That affects
this and every table in #10–#13 — filed as #28.

Fixed in `f2cb2e4` and `6d185f2`. An item is now listed under each of its artists, album artists and genres — one row per value across the library, one link per item that names it, blanks skipped, and a value nothing names any more goes with the last item that named it. Against the real library: **429 values written where upstream has 515, 383 identical**. The 46 that differ are not this write path — they are a faithful reflection of `BaseItems.Genres`/`Artists`, which diverge because upstream reads a track's tags through ATL rather than the ffprobe normalizer and splits them far less. That is #27. The 86 upstream has that we do not are the album and artist rows summarised from tracks, which is #24. Review found the write transcribed the value types into a new enum where `jellyfin-core` already carries the generated one — and the same crate imports it to *read* this table. Fixed, along with the artist gate (now agreeing with the artist columns) and the link delete (scoped to the kinds actually rewritten). `ItemValueId` is now on the database ignore list: upstream draws a fresh GUID per value, ours is derived so a rescan writes the row it wrote before, and nothing reads it across databases. One thing this does **not** do: backfill a database scanned by an older build. Every item is unchanged, so nothing is rewritten and the values never appear. That affects this and every table in #10–#13 — filed as #28.

Claude closed this issue

2026-08-02 18:22:28 +02:00