Fewer genres are recorded than upstream records #62

New issue

Closed

opened 2026-08-04 11:21:29 +02:00 by Claude · 1 comment

Claude commented

2026-08-04 11:21:29 +02:00

Collaborator

Fewer genres are recorded than upstream records from the same files.

Over /mnt/media with remote providers disabled on both sides — offline
upstream (var/big-upstream) records 231 ItemValues of type Genre where
this port records 140.

Neither number comes from the internet: that database is upstream scanning the
same files with every remote metadata and image fetcher off, which is the
comparison reference/README.md requires. So the gap is in what is read out of
the files.

Not <genre> in an NFO — the library holds none, and that path was just ported
(#61). The genres this port records come from container tags, so the likely
ground is which tag names are read, how a tag holding several is split, or which
item kinds are asked for one at all.

Found while measuring #61 and unrelated to it.

Fewer genres are recorded than upstream records from the same files. Over `/mnt/media` with remote providers disabled on both sides — offline upstream (`var/big-upstream`) records **231** `ItemValues` of type Genre where this port records **140**. Neither number comes from the internet: that database is upstream scanning the same files with every remote metadata and image fetcher off, which is the comparison `reference/README.md` requires. So the gap is in what is read out of the files. Not `<genre>` in an NFO — the library holds none, and that path was just ported (#61). The genres this port records come from container tags, so the likely ground is which tag names are read, how a tag holding several is split, or which item kinds are asked for one at all. Found while measuring #61 and unrelated to it.

Claude commented

2026-08-04 11:38:57 +02:00

Author

Collaborator

Closing this as not a defect. I filed it on a stale database and the number
was wrong.

The 140 came from var/big5, a scan taken before this session's tag-reading
fixes. Measured against var/big6, the recent music scan, the port records
223 distinct genre values where offline upstream records 231 — and the
Audio and MusicAlbum counts match upstream exactly (223 and 208).

Every one of the eight accounted for:

value	lives on	why
`Adventure`, `Animation`, `Comedy`, `Factual`	Episode	`big6` scanned music only; upstream's database covers all three libraries. A scope difference, not a reading one.
`Drum And Bass;Electronic;Neurofunk`	Audio, MusicAlbum	The stacked-tag case fixed in #44. `big6` was written at 19:45, before that merged, and still holds `Drum And Bass` and `Neurofunk` split apart.
`Glam Metal`, `OST`, `Stoner Rock`	MusicArtist only	Upstream's artist metadata refresh writes genres onto by-name artist rows. This port records no artist genres at all, and the refresh is a metadata-provider feature the project excludes.

The stronger evidence is the one already measured when #44 and #46 closed: over
the same library, 0 track rows and 0 album rows differ from upstream on
Genres. A count of distinct interned values is a weaker instrument than a
row-for-row diff, and it is the one that misled me here.

The one real thing left is the third row of that table — an artist row carries
no genres here. That belongs with the other by-name gaps rather than under a
title claiming genres are under-read, and it is a provider feature besides.

**Closing this as not a defect. I filed it on a stale database and the number was wrong.** The 140 came from `var/big5`, a scan taken before this session's tag-reading fixes. Measured against `var/big6`, the recent music scan, the port records **223** distinct genre values where offline upstream records 231 — and the Audio and MusicAlbum counts match upstream exactly (223 and 208). Every one of the eight accounted for: | value | lives on | why | |---|---|---| | `Adventure`, `Animation`, `Comedy`, `Factual` | Episode | `big6` scanned music only; upstream's database covers all three libraries. A scope difference, not a reading one. | | `Drum And Bass;Electronic;Neurofunk` | Audio, MusicAlbum | The stacked-tag case fixed in #44. `big6` was written at 19:45, before that merged, and still holds `Drum And Bass` and `Neurofunk` split apart. | | `Glam Metal`, `OST`, `Stoner Rock` | MusicArtist only | Upstream's artist metadata refresh writes genres onto by-name artist rows. This port records no artist genres at all, and the refresh is a metadata-provider feature the project excludes. | The stronger evidence is the one already measured when #44 and #46 closed: over the same library, **0** track rows and **0** album rows differ from upstream on `Genres`. A count of distinct interned values is a weaker instrument than a row-for-row diff, and it is the one that misled me here. The one real thing left is the third row of that table — an artist row carries no genres here. That belongs with the other by-name gaps rather than under a title claiming genres are under-read, and it is a provider feature besides.

Claude closed this issue

2026-08-04 11:38:57 +02:00