Parent image fields disagree with upstream in both directions #70
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?
Parent image fields are sent where upstream sends none, and missed where it
sends them.
/Items?Recursive=true&SortBy=SortName— 21,895 items, both servers on onedatabase — comes back 894,842 bytes longer than upstream's. Counted per
field over that response:
ParentBackdropImageTags/ParentBackdropItemIdParentLogoImageTag/ParentLogoItemIdAlbumPrimaryImageTagImageBlurHashesThe first two are the opposite of the third: this server walks its ancestry and
attaches a parent's backdrop and logo where upstream attaches none, while
upstream names a track's album image and this server does not.
DtoService.AttachBasicFieldsdecides each of these separately — which parentis asked, and which image types are borrowed from it — rather than by one
inheritance rule. That per-field detail is what to port.
Measured after #63 and #65, both of which moved these numbers down; this is what
is left.
ImageBlurHashesis downstream of whichever tag is wrong, so it shouldfollow the others rather than needing its own fix.
Body length is not the target — per-field differing-item counts are. The byte
figure is quoted only because it is what makes this visible in the harness,
where the response is compared on length alone.
Fixed, all four fields to zero, from one fact about upstream.
GetImageDisplayParent(DtoService.cs:1522) sends aMusicAlbumto theartist it names, not to the folder above it — and that artist is looked up
in a batch (
LinkedChildrenService.FindArtists) whose query does not includethe images navigation. So an album that names an artist gets an image-less row,
borrows nothing, and the walk ends there, because
MusicArtistdoes not inheritimages. Only an album naming an artist no row answers falls back to its real
ancestor.
That single fact accounts for all 6,330 excess
ParentBackdrop*/ParentLogo*items.
Beside it:
AddInheritedImagesreturns early unless the item itself supportsinherited images (true only for audio, albums, videos, seasons and folders —
BaseItem's default is false),AlbumPrimaryImageTagcomes from the track'sown album entity, and a blurhash is filed only when the column is non-empty.
ImageBlurHashesParentBackdropImageTags/ItemIdParentLogoImageTag/ItemIdAlbumPrimaryImageTagThe reading was validated by simulating upstream's whole walk against the
database: it reproduces
ParentLogoItemId,ParentThumbItemIdandParentBackdropItemIdfor all 21,895 items with 0 mismatches, and ablatingeither the album-to-artist redirect or the image-less-batch rule reproduces the
reported counts exactly.
One regression this caused and fixed in the same branch: search hints derived
their backdrop from the borrowed fields, which the tighter walk emptied for 7
tracks. Upstream's hint reads the raw parent chain with no inheritance rule, so
that is what it does now.