Skip to content

More proper implementation of embedded art priority - #349

Merged
htkhiem merged 11 commits into
mainfrom
fix/embedded-art-priority
Aug 31, 2026
Merged

htkhiem merged 11 commits into
mainfrom
fix/embedded-art-priority

Conversation

@htkhiem

@htkhiem htkhiem commented Aug 31, 2026 •

Copy link
Copy Markdown
Owner

Sequence

This is like, what, the 6th iteration of our album art loading algorithm? Hopefully the last.

  1. Check by folder_key in in-mem cache.
  2. If not available, check by embedded_key too.
  3. Check by folder_key on disk. If hits, cache by folder_key.
  4. Check by embedded_key on disk too. If hits, cache by embedded_key.
  5. Try fetching cover file from MPD. If hits, cache by folder key.
  6. Try fetching embedded art from MPD too. If hits, cache by folder key if embedded art optimisation is enabled, else by every single URI in the album.
  7. Try fetching from external sources. If hits, cache by folder key if embedded art optimisation is enabled, else by every single URI in the album.
  8. If we still can't find anything then write a placeholder entry into SQLite & return None.

When embedded-art optimisation is on, this matches the v0.99.6 behaviour of fetching just one image per folder, be it a cover file or a random track's embedded art. With that turned off, we STILL prefer the cover file, but now if one does not exist, we fetch every track's embedded art individually.

Custom album arts are keyed at the track URI level if said optimisation is disabled (just like external sources or embedded art from MPD). Assuming the library remains constant and MPD doesn't change its behaviour, then the representative track for each album (fetched with window size 1) should always be the first track, and by using its URI as the embedded key of that album, the custom arts should be persisted across boots. This allows customising album arts even in libraries that don't follow the one-release-per-folder rule.

General guidelines

  • Try to keep your last-level folders to a single "release" (album). With this, the above optimisation can be turned on without issue. This does not even require a cover.{png,webp,jpg} file as Euphonica will just read the embedded art of one track and use it for all other tracks too.
  • In case you have some "mixed" folders, in which there are tracks from different albums, do these:
    • Disable the above optimisation (either choose "Mixed" at the onboarding wizard's Library organisation page or go to Preferences -> Library -> disable Optimise embedded cover loading), and
    • DO NOT place a cover.{png,webp,jpg} file in those folders. Even with the optimisation disabled, Euphonica will still try to opportunistically use said file (steps 1, 3 and 5 are always active in the above sequence).
    • If your library still has some single-release folders, PLACE cover.{png,webp,jpg} FILES IN THEM. Without the optimisation, these files are required to prevent Euphonica from downloading the same embedded art again and again for every track in the same release.

Rationale

In case the above still sounds so stupid, pls hear me out:

  • The blanket "always pick just one image per folder" trick caters to libraries that are organised into single-release folders but do NOT have separate cover files. Without the optimisation, every embedded art from every track would be downloaded, blowing up the cache size and RAM usage.
  • Steps 1, 3 and 5 being always-on is to allow libraries that are "almost there" in terms of folder organisation to benefit from the same optimisation without forcing it on by manually providing separate cover.{png,webp,jpg} files for folders that are single-release, and fall back to per-track embedded art for folders that aren't. I suppose the majority of people will have libraries that fall into this category (a few "unorganised" folders).
  • For libraries that are wholly NOT organised into single-release folders and do NOT have any cover.{png,webp,jpg} files, steps 1, 3 and 5 do nothing on their own and disabling the optimisation enables step 6 to write at track-URI level, correctly resolving one album art for every track.
    • Downside: if tracks of an album are scattered or duplicated over multiple folders, their album arts will be downloaded once for each folder the tracks are in, thereby still resulting in duplicate downloads.

Other changes

  • Fixed a bunch of issues with DP cover saving across renames.
  • Filled in a lot of missing image-changed signals and listeners, so now changing one image (cover/avatar) will correctly propagate across the app and even to the blurred background.

@htkhiem

htkhiem commented Aug 31, 2026

Copy link
Copy Markdown
Owner Author

Onboarding wizard now reworded as follows:

image

@htkhiem htkhiem linked an issue Aug 31, 2026 that may be closed by this pull request
@aaravrav

Copy link
Copy Markdown
Contributor

This isn’t really constructive, but as a new user, I'd have no idea what the wizard is talking about, and I kind of still don't right now

@aaravrav

aaravrav commented Aug 31, 2026 •

Copy link
Copy Markdown
Contributor

Also Im confused by what the visuals could possibly mean/be referring to

@htkhiem

htkhiem commented Aug 31, 2026 •

Copy link
Copy Markdown
Owner Author

Yea I haven't found an simpler way to describe it. The idea is that

  • Some people put all their tracks in a single folder
  • Some others create folders for mixes, playlists, etc
  • Yet others, mostly those using auto-tagging solutions like me, create one folder for each album.

The above variety of layout creates difficulties in loading album arts as we can't easily make assumptions about how the album arts are made available. Catering to one (one folder per album, with or without cover files) will leave the other (tracks from many albums but stored in the same folder) out.

As for the visuals, they change depending on your selection. In the first option, each folder contains only one shape type, signifying all tracks in that folder being from the same release. In the second option (pictured below) they're mixed up.

image

If you could come up with anything less verbose than the mess above I'm all ears.

EDIT: it's probably the subtitles. They're way too technical and do more harm than good. What if we simply don't display the subtitles at all and just document it online in the repo wiki instead?

Just refresh the whole list :))
…ration for user set/unset + fix dyn playlist cover set/unset
@htkhiem

htkhiem commented Aug 31, 2026

Copy link
Copy Markdown
Owner Author
image

This isn't explicit about what Euphonica does under the hood which IMHO goes against the "full disclosure" UX that I personally like. For example, Cantata gives really detailed explanations about what each setting does.

Maybe we can drop a "Learn more" link to the repo later I guess, but for now this does look less intimidating.

@htkhiem
htkhiem merged commit 33b285d into main Aug 31, 2026
@htkhiem
htkhiem deleted the fix/embedded-art-priority branch August 31, 2026 16:03
@aaravrav

aaravrav commented Sep 1, 2026 •

Copy link
Copy Markdown
Contributor
image

Currently there's no indication that the diagram would change upon selecting another option. How about something like this? 2 large buttons side-to-side

@htkhiem

@aaravrav

aaravrav commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

nitpick but maybe there isn't a reason to add the subtitle explaining why euphonica needs it, perhaps put the explanation in a tooltip behind a help icon (?) instead

@aaravrav aaravrav mentioned this pull request Sep 1, 2026
@htkhiem htkhiem mentioned this pull request Sep 19, 2026
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.

Issue with images

2 participants