Fix a track started directly never falling back to its album's artwork #24

Merged

kyuno merged 2 commits from fix/track-image-albumid-fallback into master 2026-09-18 11:36:35 +02:00

Conversation 0 Commits 2 Files changed 4 +71 -2

kyuno commented 2026-09-18 10:26:56 +02:00

Owner

Copy link

Summary

One concrete, confirmed cause behind "the app struggles to find artist/album/track images."

imageUrlFor's own Audio -> AlbumId fallback (added earlier specifically because a track essentially never has its own Primary image, only its album usually does) was silently never triggering for a track played directly — not via its album or artist — because the raw item that decision runs against, CatalogService.getRawItem, never requested AlbumId from Emby. Emby's default field set for a single-item GET omits it entirely, so item.AlbumId read undefined regardless of whether the track's actual album genuinely had one — falling through to the track's own id every time.

Every other path that resolves a track's image already asks for AlbumId correctly (getAlbumTracks/getPlaylistItemsRaw), which is why launching a whole album/artist/playlist was never affected. Fixed the one gap: getRawItem now requests Fields=AlbumId too — harmless for every non-Audio item it also fetches.

Not the whole story, most likely — a real Emby library can also legitimately have no Primary image at all for a given artist/album (nothing to fall back to, not a bug). Flagged directly in docs/architecture.md rather than overclaiming "images are fixed" — worth a more specific follow-up report if artist/album art still struggles after this.

Test plan

• npm run typecheck/npm test/npm run build (server) — clean, 148/148
• New test confirms getRawItem's actual outgoing request includes Fields=AlbumId (a mocked EmbyClient.fetch capturing the real path/query, not just re-asserting the already-separately-tested imageUrlFor logic downstream of it)

🤖 Generated with Claude Code

## Summary One concrete, confirmed cause behind "the app struggles to find artist/album/track images." `imageUrlFor`'s own `Audio -> AlbumId` fallback (added earlier specifically because a track essentially never has its own Primary image, only its album usually does) was silently never triggering for a track played directly — not via its album or artist — because the raw item that decision runs against, `CatalogService.getRawItem`, never requested `AlbumId` from Emby. Emby's default field set for a single-item GET omits it entirely, so `item.AlbumId` read `undefined` regardless of whether the track's actual album genuinely had one — falling through to the track's own id every time. Every other path that resolves a track's image already asks for `AlbumId` correctly (`getAlbumTracks`/`getPlaylistItemsRaw`), which is why launching a whole album/artist/playlist was never affected. Fixed the one gap: `getRawItem` now requests `Fields=AlbumId` too — harmless for every non-Audio item it also fetches. **Not the whole story, most likely** — a real Emby library can also legitimately have no Primary image at all for a given artist/album (nothing to fall back to, not a bug). Flagged directly in docs/architecture.md rather than overclaiming "images are fixed" — worth a more specific follow-up report if artist/album art still struggles after this. ## Test plan - [x] `npm run typecheck`/`npm test`/`npm run build` (server) — clean, 148/148 - [x] New test confirms `getRawItem`'s actual outgoing request includes `Fields=AlbumId` (a mocked `EmbyClient.fetch` capturing the real path/query, not just re-asserting the already-separately-tested `imageUrlFor` logic downstream of it) 🤖 Generated with [Claude Code](https://claude.com/claude-code)

kyuno added 1 commit 2026-09-18 10:26:56 +02:00

Fix a track started directly never falling back to its albums artwork ... 5b2b832be7

imageUrlFors own Audio -> AlbumId fallback was silently never
triggering for a track played directly (not via its album/artist),
because the raw item that decision runs against - CatalogService
getRawItem - never requested AlbumId from Emby. Its default field set
for a single-item GET omits it entirely, so item.AlbumId read
undefined regardless of whether the tracks actual album had one -
falling through to the tracks own id every time, which essentially
never has a Primary image of its own. Every other path that resolves a
tracks image already asks for AlbumId correctly (getAlbumTracks/
getPlaylistItemsRaw), which is why launching a whole album/artist/
playlist was never affected. Fixed the one gap: getRawItem now
requests Fields=AlbumId too.

Flagged directly as probably not the whole images-are-hard-to-find
story - a real Emby library can also legitimately have no Primary
image at all for a given artist/album, which is not a bug this app can
fix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

kyuno added 1 commit 2026-09-18 11:36:24 +02:00

Merge remote-tracking branch 'origin/master' into fix/track-image-albumid-fallback ... 6bec09ae20

# Conflicts:
#	README.md
#	docs/architecture.md

kyuno merged commit 310dcd422e into master 2026-09-18 11:36:35 +02:00

kyuno deleted branch fix/track-image-albumid-fallback 2026-09-18 11:36:35 +02:00

kyuno referenced this pull request from a commit 2026-09-18 11:36:35 +02:00

Merge pull request 'Fix a track started directly never falling back to its album's artwork' (#24) from fix/track-image-albumid-fallback into master

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: kyuno/watchparty#24

No description provided.