Duplicate cached cover art (same cover art downloaded for each track in album)

[FibreTTP]

While checking that the cover art filename sanitation implemented in #533 was working, I noticed that I had 54 images of the same Skyrim Original Game Soundtrack cover art in my Supersonic cache folder:

This occurs when opening the Play Queue in Supersonic. Scrolling through the queue downloads each track's front cover:

The problem is, I don't know where to place the blame for this.

• Supersonic is right, since different tracks in an album may have track specific covers.
• LMS is right, since Supersonic is specifically requesting each track's cover.

Ultimately, each file is only ~20 KiB, so not a huge deal. But I do believe this behaviour is not ideal, and can be solved with hashing on the client or server side.

Pinging @epoupon for discussion (I don't know if this happens on other music servers).

[epoupon]

On LMS side:

• if a track has an embedded cover, an id to this track is encoded to the coverArt field for the track (+ a timestamp of the last modification time of the track). lms does not dedup images within tracks for each album
• else if a track belongs to an album that has a file cover art, an id to this release is encoded to the coverArt field for the track (+ a timestamp of the last modification time of the cover file)

[dweymouth]

I think that's pretty much the same as Navidrome's implementation. I think the "issue" is that there's no good way to de-duplicate embedded images. Binary comparison is too slow and error-prone. Navidrome has a server-side setting to prefer external art even for track cover images when the files do have embedded art (to avoid this duplication scenario). LMS could consider adding that as well. I could also consider adding such a setting to Supersonic, but it would be more efficient to solve server-side. Because otherwise Supersonic would have to first make an HTTP request to get a track's parent album, and then a second HTTP request to fetch the album cover art. @FibreTTP what do you think?

[epoupon]

Yes it could work, but maybe one day, we will extend OS with more info for each track/album like multi cover support (front, back) and some people already request for covers per disc etc.
No sure we will manage to handle all this with some server specific params, it looks like clients are best suited to chose what they want.

[dweymouth]

Maybe it makes sense to add an albumCoverArt property to OpenSubsonic track objects then, so clients could choose to show the album art without having to fetch the full album just to know the cover art id?

[FibreTTP]

Looking at the OpenSubsonic docs, getCoverArt requires an ID that is returned by Child (a track), albumID3, ArtistID3, albuminfo, etc., as the coverArt field.

Could a music server compute a hash for each image it processes (at scan-time), and use this hash as the coverArt ID?

A client would then only request an image if it cannot find this hash in its database.

[epoupon]

Why not! This would add some extra logic on server side (need to keep a list of tracks/files for each "hash", in case some files/tracks are removed or whatever). Ideally, the id would be something opaque and the hash itself would be kept internal to the server.

[epoupon]

I did some tests on my library.

The images embedded in the tracks average 130 KiB each.
Each image is duplicated about 11 times on average, I guess this is about the average number of tracks per album.
For a large set of tracks, this represents a huge volume!
So yes, I am definitely willing to implement deduplication on LMS side.