Refresh cover for single albums

Feature description:

It would be nice if we could refresh the cover for single albums, insted of deleting the cache and loading everything again.

Problem solved:

It seems that once the cover of an album is loaded, it doesn’t reload unless I delete all the image cache. This is a problem when there is a wrong cover and it is updated in the server, as the corrected cover is not loaded. Being able to refresh the specific album would solve this.

Brought benefits:

The main benefit would be to load covers that are updated in the server without deleting the whole image cache.

Other application solutions:

If other applications have solved this, please describe their solution (If it fits your needs, else explain why their solution is not perfect)

Additional description and context:

The more details the better to understand the need and figure out the best solution.

Screenshots / Mockup:

If possible please provide screenshots of your idea of the implementation or how other application do this.

What media provider?

I’m currently using Navidrome

I think new navidrome 0.49 now return different urls when the images changes and should be handle automatically when syncing.


I will update Navidrome later today and see if now the covers are updated automatically :slight_smile:

Yes, if anything in an album changes (music, cover.jpg…) it will change the cover URL.

Ops, sorry, but no: URLs are not recreated with changes to the library.

And doesn’t seem like there is a changed field in the Album response that could be used by Symfonium to detect changes in the library.

The problem is not to detect that there’s a change, but what changed in this case the image.

Not having a way to detect that an image changed means either assuming the cache is still valid or downloading again all images each time (so same as clearing cache as he does)

Well, better to re-fetch covers from all changed albums than from all albums :slight_smile:

Anyway, not a great solution, I agree. I’ll see if I can change the coverArt attribute of the Album (and Artist) when images changes, or at least when the album changes.

Subsonic does not support differential sync, so Symfonium can’t do differential sync, so it sync everything when it sync. So for Symfonium all albums are “changed” on each sync.

Doing half differential sync, to maybe half solve an issue for maybe half of the servers does not sounds great either. Only performance downsides.

What I’m proposing is to Symfonium refetch the album art if coverArt changes, the same you proposed here: Refresh cover for single albums - #4 by Tolriq

The only issue is that I may not be able to change it only on cover changes, but on any changes to the album. I think this is still better than having to clear the app’s image cache and redownload all covers again, as albums rarely change once they are imported and properly tagged.

EDIT: Base on what you said in the linked reply, you won’t have to do anything as this is already Symfonium’s behaviour, right?

Yes that would work and is already handled on Symfonium side.

I more answered on the changed field that is not enough for that.

So if you can change on server side it’s nice, just don’t really have a proper solution on client side except targeted cache cleanup that is not always possible.

It is building now: Add lastUpdated to `coverArt` ids by deluan · Pull Request #2157 · navidrome/navidrome · GitHub. Binaries should be available in ~20 minutes (they will be attached to the PR by github-bot).

If you guys can help me test it, it would be much appreciated.

Testing the last master build and it seems it returns default images for albums without art and not 404 as for the artists now. Can this be fixed ?

Are you sure? The /share/img URLs returned in getXxxxInfo should never return placeholders. I just tested it locally with a URL from getAlbumInfo2:

In that case it’s values returned as covertArt so
getCovertArt id=al-43946ea749f087aa564d518276aa9ea5_5374cf86

When replaced by the url from getAlbumInfo I do get the 404 but the search3 endpoint still only return / support the covertArt I think no ?

Hum and just tilting but the urls for the /share contains the ip and port.

How are those generated ?

It’s based on the IP requested at the time of the getInfo? That can be problematic if the host can be accessed by 2 different IPs when in and out of home and things like that no?

Yes getCoverArt returns a placeholder if the image is not available, as the original Subsonic call. This hasn’t change in latest versions. Any suggestions?

It’s based on the IP requested at the time of the getInfo? That can be problematic if the host can be accessed by 2 different IPs when in and out of home and things like that no?

This is the logic to detect the server schema/host:

It basically extracts the address received by the client request. It works in the situation you described and also works behind proxies. If I ever get a complain about this, I may introduce a config option to set this.

Well it can’t really work if you do the calls to getXXInfo2 you get the urls with localIP that are stored in the DB and then when called from outside those urls are no more valid and would require calling those again.

Do like the artists and don’t return the covertArt? or expose the url in a new field as done for the artists?

The URLs are generated at request time, not from a cache in the DB. If you call getArtistInfo using http://localhost:4533/rest/getArtistInfo2.view, you’ll get a http://localhost:4533/share/img URL. If you call, you’ll get a URL, even if you get the localhost one first.

Do like the artists and don’t return the covertArt? or expose the url in a new field as done for the artists?

Artists endpoint always return a coverArt field. Remember cover art is resolved at request time, not at scan time, due to its dependency on external sources. Chicken or Egg issue. I could expose the share url in a new field albumImageUrl, but then you’d have to handle this differently than other Subsonic API implementations…

Unless you are talking about the client DB, in that case, yeah, this won’t work. The best I can do is to add a config option to force a specific URL and override this behaviour. I’ll do some testing with relative paths as well (/share/img/xxxx, without the server address), what do you think?