A scan writes no rows for the names it records #57
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A scan writes no rows for the names it records.
Upstream's scan creates a
BaseItemsrow per genre, studio and artist it sees —GenresValidator,MusicGenresValidator,StudiosValidator— and the by-namelistings are queries over those rows. This server's scan writes none, except the
MusicArtistrows an artist folder produces.The listings still answer, because they fall back to deriving names from
ItemValuesfor anything no row stands for. On a library upstream scanned thatfallback contributes nothing (measured: zero orphan values across all five
listings), so a database written by upstream reads identically either way.
On a library this server scanned, the difference is everything the listings
report about a name: a row carries a sort name, an id that survives a rescan,
images, and a date. Derived names have none of that, which is why an id from
/Genres/{name}still disagrees with upstream's.MILESTONES.mdstates that a by-name item is never a row here. That is the rulethis issue proposes changing, so the sentence wants revisiting with it.
A scan now writes the rows, as upstream's validators do.
Upstream runs
GenresValidator,MusicGenresValidator,StudiosValidatorandArtistsValidatorafter a scan. Each takes its names fromGetItemValueNames(
ItemValuesMap ⋈ ItemValues, grouped onCleanValue, takingMIN(Value)) andcalls
CreateItemByNameper name. The genre split is by owner type —GetGenreNamesexcludesItemTypeLookup.MusicGenreTypes,GetMusicGenreNamesrequires them.
The id is the part that had to be exact:
GetItemByNameId<T>(T.GetPath(name))makes the path relative to the program data directory, swaps separators,
lowercases it, prefixes the .NET type name, and takes MD5 over UTF-16LE.
GetValidFilenamemaps" < > | : * ? \ /and the C0 range to spaces, and aperson is filed under the first letter-or-digit of that.
Measured over 4889 tracks:
MusicGenrerowsMusicArtistrowsAll 220 music genre rows are identical to upstream's on id, name, sort name,
presentation key, path and folder flag. 174 of 185 artist rows are identical on
every column; the other 11 differ only on
SortName, which is a pre-existingfolding gap — upstream transliterates CJK to pinyin and maps
Ø→O,®→rwhereNFD does not — and is present in the before database too. Upstream's four extra
genres come from artist metadata refresh, which is a separate ingest gap.
The id derivation matches even where it degenerates: an artist named
?????has an empty valid filename, and both servers hash
metadata\artists.A rescan writes nothing —
named=0, andDateLastSavedon all 405 rows isbyte-identical to the first run.
What the listings report changed even where their membership did not: every
music genre now carries a real
DateCreatedwhere it had the lowest date, andan
Etagwhere it had none.The one claim the work could not check itself was
IsFolder, being the onlyexisting read-path output it changed. Confirmed against a running upstream
afterwards: a genre, a music genre, a studio and a by-name artist all omit the
field, while an artist that is a real folder on disk reports
true. Both holdhere now.
Left undone and worth their own issues:
PeopleValidatorand years are stillderived rather than written, this port records no
Studiosvalues for thestudio validator to act on, and the
sort_name/fold_diacriticsgaps above arenow visible in the rows as well as in the items.