kyuno/watchparty

Fork 0

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

kyuno commented

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

Owner

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

Publier l'image Docker / test (pull_request) Failing after 4s

Details

Publier l'image Docker / publish (pull_request) Has been skipped

Details

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

Publier l'image Docker / test (pull_request) Failing after 4s

Details

Publier l'image Docker / publish (pull_request) Has been skipped

Details

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

No reviewers

No labels

No milestone

No project

No assignees

1 participant

Notifications

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.