A photo does not serve the album it hangs from #234

New issue

Closed

opened 2026-09-16 01:50:25 +02:00 by Claude · 1 comment

Claude commented

2026-09-16 01:50:25 +02:00

Collaborator

#225 serves the twelve stored photo fields on BaseItemDto. Upstream's SetPhotoProperties ends with two more that are not served: Album and AlbumId, taken from the photo's AlbumEntity.

Why it was left

AlbumEntity resolves the PhotoAlbum the picture hangs from. Nothing in this port files photo albums yet — #209 named the gap: a PhotoAlbum takes no folder image, and the walk does not treat a picture's directory as an album.

So the fields are absent here while upstream names the containing folder on every photo in one.

Verifying

Once photo albums are filed, a route test over a picture in one can fail on both fields. Until then this is waiting on the album, not on the mapping.

Found reviewing #225.

#225 serves the twelve stored photo fields on `BaseItemDto`. Upstream's `SetPhotoProperties` ends with two more that are not served: `Album` and `AlbumId`, taken from the photo's `AlbumEntity`. ## Why it was left `AlbumEntity` resolves the `PhotoAlbum` the picture hangs from. Nothing in this port files photo albums yet — #209 named the gap: a `PhotoAlbum` takes no folder image, and the walk does not treat a picture's directory as an album. So the fields are absent here while upstream names the containing folder on every photo in one. ## Verifying Once photo albums are filed, a route test over a picture in one can fail on both fields. Until then this is waiting on the album, not on the mapping. Found reviewing #225.

Claude referenced this issue

2026-09-16 02:25:49 +02:00

A photo's camera, exposure and location are stored but never served #225

Claude commented

2026-09-16 07:21:15 +02:00

Author

Collaborator

Fixed, and landed on main at ec3a4ee8.

The premise this was filed on is stale: photo albums are filed. A folder holding a picture becomes a PhotoAlbum, it takes a folder image, and the answer key carries upstream's own album rows with matching parents. What was missing was only the mapping.

A photo now names the album it sits in — the nearest PhotoAlbum above it, which is upstream's AlbumEntity — serving Album and AlbumId.

Two gates were drawn while doing it, because a photo must not borrow an album's musical fields: AlbumPrimaryImageTag is served for audio and audiobooks, as upstream serves it in its audio branch alone, and the same for the normalization gain. The review caught that the first attempt at the gain used "carries artists", which would have dropped an audiobook — upstream's branch is item is Audio, and an audiobook is one. An audiobook under an album carrying loudness now reports the same gain as the track beside it.

The Album name itself is served for a track, a music video and a photo, which is the three places upstream sets it.

Fixed, and landed on `main` at `ec3a4ee8`. The premise this was filed on is stale: photo albums **are** filed. A folder holding a picture becomes a `PhotoAlbum`, it takes a folder image, and the answer key carries upstream's own album rows with matching parents. What was missing was only the mapping. A photo now names the album it sits in — the nearest `PhotoAlbum` above it, which is upstream's `AlbumEntity` — serving `Album` and `AlbumId`. Two gates were drawn while doing it, because a photo must not borrow an album's musical fields: `AlbumPrimaryImageTag` is served for audio and audiobooks, as upstream serves it in its audio branch alone, and the same for the normalization gain. The review caught that the first attempt at the gain used "carries artists", which would have dropped an audiobook — upstream's branch is `item is Audio`, and an audiobook is one. An audiobook under an album carrying loudness now reports the same gain as the track beside it. The `Album` name itself is served for a track, a music video and a photo, which is the three places upstream sets it.

Claude closed this issue

2026-09-16 07:21:16 +02:00