Two album artists are missing from the album artist list #53

New issue

Closed

opened 2026-08-03 22:33:31 +02:00 by Claude · 1 comment

Claude commented

2026-08-03 22:33:31 +02:00

Collaborator

Two album artists are missing from /Artists/AlbumArtists.

	upstream	ours
total	100	98

The two upstream lists and this server does not are Fall Out Boy and
Scooter & Harris & Ford. Nothing is listed here that upstream does not, so the
answer is short rather than different.

Both names are ones a splitter would have opinions about — one holds an
ampersand, the other holds two — so the likely cause is how a track's album
artist is cut into names, not the route itself.

Measured over 4889 tracks. Every other album artist agrees, and the artist rows
themselves are unaffected.

Two album artists are missing from `/Artists/AlbumArtists`. | | upstream | ours | |---|---|---| | total | 100 | **98** | The two upstream lists and this server does not are `Fall Out Boy` and `Scooter & Harris & Ford`. Nothing is listed here that upstream does not, so the answer is short rather than different. Both names are ones a splitter would have opinions about — one holds an ampersand, the other holds two — so the likely cause is how a track's album artist is cut into names, not the route itself. Measured over 4889 tracks. Every other album artist agrees, and the artist rows themselves are unaffected.

Claude referenced this issue

2026-08-03 23:05:24 +02:00

An id that names nothing is answered rather than refused #48

Claude referenced this issue

2026-08-03 23:36:27 +02:00

Genres and MusicGenres both answer with every genre #52

Claude commented

2026-08-03 23:36:28 +02:00

Author

Collaborator

Both issues were one cause, and it was not the scanner: both servers read copies
of the same upstream-written database, so how a name is split never came into it.

The by-name listings walked ItemValues and grouped by CleanValue. Upstream
queries BaseItems (BaseItemRepository.ByName.cs, GetItemValues): rows of
the item type the route names, one per PresentationUniqueKey, whose
CleanName matches a value of the given type in reach.

#52 — one value type, two item types. Genre and MusicGenre are
different rows over the same values, and GenresController switches to the
music kind when the parent is a music library. Neither was done here.
#53 — Fall Out Boy / Fall Out Boy and Scooter & Harris & Ford /
Scooter, Harris & Ford are two rows each sharing one folded name. Grouping
by clean value collapsed each pair; upstream lists both.

Measured over one production database, both servers, identical ordering as well
as counts:

route	before	after	upstream
`/Genres`	172	46	46
`/MusicGenres`	172	142	142
`/Artists/AlbumArtists`	98	100	100
`/Artists`	181	183	183
`/Studios`	813	827	827

/Items/Filters2 picks the genre kind the same way and reads the same listing.

Two things worth recording. Upstream answers these from rows alone and returns
nothing where a scan never created them; this server's scan writes no
Genre/MusicGenre/Studio rows at all, so the derive-from-values fallback is
kept for names no row stands for, now under upstream's own owner-type rule. On
any database upstream scanned the fallback adds nothing — measured, zero orphan
values across all five listings. That this port's scan has no validator
equivalent is a real gap, and is filed separately.

MILESTONES.md says a by-name item is never a row here, which is no longer
true.

Both issues were one cause, and it was not the scanner: both servers read copies of the same upstream-written database, so how a name is split never came into it. The by-name listings walked `ItemValues` and grouped by `CleanValue`. Upstream queries `BaseItems` (`BaseItemRepository.ByName.cs`, `GetItemValues`): rows of the *item type* the route names, one per `PresentationUniqueKey`, whose `CleanName` matches a value of the given type in reach. - **#52** — one value type, two item types. `Genre` and `MusicGenre` are different rows over the same values, and `GenresController` switches to the music kind when the parent is a music library. Neither was done here. - **#53** — `Fall Out Boy` / `Fall Out Boy ` and `Scooter & Harris & Ford` / `Scooter, Harris & Ford` are two rows each sharing one folded name. Grouping by clean value collapsed each pair; upstream lists both. Measured over one production database, both servers, identical ordering as well as counts: | route | before | after | upstream | |---|---|---|---| | `/Genres` | 172 | **46** | 46 | | `/MusicGenres` | 172 | **142** | 142 | | `/Artists/AlbumArtists` | 98 | **100** | 100 | | `/Artists` | 181 | **183** | 183 | | `/Studios` | 813 | **827** | 827 | `/Items/Filters2` picks the genre kind the same way and reads the same listing. Two things worth recording. Upstream answers these from rows alone and returns nothing where a scan never created them; this server's scan writes no `Genre`/`MusicGenre`/`Studio` rows at all, so the derive-from-values fallback is kept for names no row stands for, now under upstream's own owner-type rule. On any database upstream scanned the fallback adds nothing — measured, zero orphan values across all five listings. **That this port's scan has no validator equivalent is a real gap**, and is filed separately. `MILESTONES.md` says a by-name item is never a row here, which is no longer true.

Claude closed this issue

2026-08-03 23:36:28 +02:00