Skip to content

api + web: pull album art on first view, not first CDJ load#22

Merged
vynulldev merged 1 commit into
mainfrom
artwork-lazy
Jul 20, 2026
Merged

api + web: pull album art on first view, not first CDJ load#22
vynulldev merged 1 commit into
mainfrom
artwork-lazy

Conversation

@vynulldev

Copy link
Copy Markdown
Owner

What & why

Newly added tracks showed no artwork in the web UI until a CDJ loaded them. The add path only reads the tag-embedded picture, which misses art ffmpeg can see, and the artwork endpoint's lazy extraction (one probe on first request, then cached for good) was unreachable from the UI: every render site gated the img on art_id > 0, so the request that would have triggered extraction was never made. Loading the track on a deck ran analysis, whose artwork write-back set art_id, and only then did the UI show art, a chicken-and-egg the CDJ happened to break.

The track payload now carries art_checked (the server-side "has this file ever been probed" flag), and a shared artHTML helper, replacing three copy-pasted render sites (table ART column, mobile card, detail drawer), renders the img optimistically whenever the file has never been probed: the first view of a new track fires the artwork request, the endpoint extracts synchronously, and the same response delivers the image. Tracks probed and found artless go straight to the placeholder, so there is no repeated 404 traffic, and an onerror fallback covers the artless and concurrent-probe cases.

Verified in the browser against a fresh library: a never-probed track with embedded art shows it on first open of the detail drawer with art_id and art_checked persisted behind it, an artless track degrades to the placeholder, and after its probe it makes no further artwork requests across a reload.

Hardware testing

  • Tested on: N/A: no deck-facing change. The dbserver artwork path CDJs use is untouched; this only adds a field to the HTTP track payload and changes how the web UI requests art.

Checklist

  • go build ./..., go vet ./..., and go test ./... pass
  • gofmt -l . is clean
  • New source files carry an SPDX header (GPL-3.0-or-later) (n/a, no new files)
  • Tested on real hardware (deck + firmware noted above), or this change doesn't affect deck behaviour
  • I agree my contribution is licensed under the project's GPLv3

Newly added tracks showed no artwork in the web UI until a CDJ loaded
them. The add path only reads the tag-embedded picture, which misses
art ffmpeg can see, and the artwork endpoint's lazy extraction (one
probe on first request, then cached for good) was unreachable from the
UI: every render site gated the <img> on art_id > 0, so the request
that would have triggered extraction was never made. Loading the track
on a deck ran analysis, whose artwork write-back set art_id, and only
then did the UI show art - a chicken-and-egg the CDJ happened to break.

The track payload now carries art_checked, and a shared artHTML helper
renders the <img> optimistically whenever the file has never been
probed: the first view of a new track fires the artwork request, the
endpoint extracts synchronously, and the same response delivers the
image. Tracks probed and found artless go straight to the placeholder
(no repeated 404 traffic) and an onerror fallback covers the artless
and concurrent-probe cases.

Verified in the browser against a fresh library: a never-probed track
with embedded art shows it on first open of the detail drawer with
art_id and art_checked persisted, an artless track degrades to the
placeholder, and after its probe it makes no further artwork requests.
@vynulldev
vynulldev merged commit b7f17a8 into main Jul 20, 2026
1 check passed
@vynulldev
vynulldev deleted the artwork-lazy branch July 20, 2026 20:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant