BaseItemProviders is never written #11

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

BaseItemProviders holds 19 495 rows upstream and 0 here.

Two sources, both available without a network call:

the folder names in this library already carry them —
Alien (1979) [imdbid-tt0078748] - Directors Cut [...].mkv
container tags carry MusicBrainz ids —
MusicBrainzAlbum, MusicBrainzArtist, MusicBrainzRecording, …

jellyfin-core/src/rows.rs and jellyfin-db/src/items.rs already read the
table. Without it, external links and anything a client keys on a provider id
are dead.

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.

`BaseItemProviders` holds **19 495** rows upstream and 0 here. Two sources, both available without a network call: - the folder names in this library already carry them — `Alien (1979) [imdbid-tt0078748] - Directors Cut [...].mkv` - container tags carry MusicBrainz ids — `MusicBrainzAlbum`, `MusicBrainzArtist`, `MusicBrainzRecording`, … `jellyfin-core/src/rows.rs` and `jellyfin-db/src/items.rs` already read the table. Without it, external links and anything a client keys on a provider id are dead. --- 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 database scanned by an older build keeps what that build did not write #28

Claude commented

2026-08-02 20:56:41 +02:00

Author

Collaborator

Fixed in d87b58f, 7ae0714, 03981b2 and faaea74.

Three sources, none of them a network call: the bracketed attributes in a path,
a .nfo beside the item, and the tags inside the file.

Verified against the real library: 17051 rows, every one of them upstream's —
0 values disagreeing and 0 rows upstream does not also have (was 0 rows).

	upstream	ours
`BaseItemProviders`	19511	17051
rows we write that upstream does not		0
rows we write with a different value		0

What upstream still has that we do not, all of it accounted for:

rows	what	where it belongs
943	album and artist ids — 278 albums × 3, 72 artists, 39 `AudioDbArtist`	#24: nothing is summarised from an album's tracks
1413	`MusicBrainzRecording`, every one an mp3	below
102	`MusicBrainzTrack` whose value is in no tag of the file	not derivable from what is on disk

The mp3s are Picard's doing: it writes the recording id into the ID3 UFID
frame rather than a text frame, and ffprobe does not report UFID at all. Every
file whose recording id is in a text tag — flac, m4a, ogg — has it. Filed
separately.

The 102 are stranger: the file carries no release-track id in any spelling, and
upstream stored one anyway. Nothing on disk says where it came from.

MetadataProvider is generated now, because the table stores a provider by name
and the name upstream stores is the enum's own spelling — musicbrainzalbum in
an NFO is MusicBrainzAlbum in the table, and one upstream has no name for is
stored as written.

Getting there took three rounds of review, and each found something the port had
wrong rather than merely missing:

an id under an actor became the item's own. The NFO reader walked into
every element, so <actor><tmdbid> and even a <tmdbid> inside a comment
were read as the film's — and being later in the document, they won. It reads
the root's children now and skips past what each of them holds.
the two commonest Kodi shapes were not read at all. <id TMDB="…"> and a
bare provider link after the document — a .nfo that is nothing but an IMDb
URL is a real thing and yielded nothing.
the tags beat the metadata file. Upstream's prober is a pre-refresh
provider, so the file's tags are read before the .nfo and lose to it. Ours
had them last. Latent today — no track has an NFO and no video's tags carry an
id — but wrong.
MusicBrainzRecording came from nowhere. It is upstream's second read of
the file rather than its prober's, and it is 3050 of the 19511 rows.

Fixed in `d87b58f`, `7ae0714`, `03981b2` and `faaea74`. Three sources, none of them a network call: the bracketed attributes in a path, a `.nfo` beside the item, and the tags inside the file. **Verified against the real library: 17051 rows, every one of them upstream's — 0 values disagreeing and 0 rows upstream does not also have** (was 0 rows). | | upstream | ours | |---|---|---| | `BaseItemProviders` | 19511 | **17051** | | rows we write that upstream does not | | 0 | | rows we write with a different value | | 0 | What upstream still has that we do not, all of it accounted for: | rows | what | where it belongs | |---|---|---| | 943 | album and artist ids — 278 albums × 3, 72 artists, 39 `AudioDbArtist` | #24: nothing is summarised from an album's tracks | | 1413 | `MusicBrainzRecording`, every one an mp3 | below | | 102 | `MusicBrainzTrack` whose value is in no tag of the file | not derivable from what is on disk | The mp3s are Picard's doing: it writes the recording id into the ID3 `UFID` frame rather than a text frame, and ffprobe does not report `UFID` at all. Every file whose recording id is in a text tag — flac, m4a, ogg — has it. Filed separately. The 102 are stranger: the file carries no release-track id in any spelling, and upstream stored one anyway. Nothing on disk says where it came from. --- `MetadataProvider` is generated now, because the table stores a provider by name and the name upstream stores is the enum's own spelling — `musicbrainzalbum` in an NFO is `MusicBrainzAlbum` in the table, and one upstream has no name for is stored as written. Getting there took three rounds of review, and each found something the port had wrong rather than merely missing: - **an id under an actor became the item's own.** The NFO reader walked into every element, so `<actor><tmdbid>` and even a `<tmdbid>` inside a comment were read as the film's — and being later in the document, they won. It reads the root's children now and skips past what each of them holds. - **the two commonest Kodi shapes were not read at all.** `<id TMDB="…">` and a bare provider link after the document — a `.nfo` that is nothing but an IMDb URL is a real thing and yielded nothing. - **the tags beat the metadata file.** Upstream's prober is a pre-refresh provider, so the file's tags are read *before* the `.nfo` and lose to it. Ours had them last. Latent today — no track has an NFO and no video's tags carry an id — but wrong. - **`MusicBrainzRecording` came from nowhere.** It is upstream's second read of the file rather than its prober's, and it is 3050 of the 19511 rows.

Claude closed this issue

2026-08-02 20:56:59 +02:00