GNOME Bugzilla – Bug 346852
Delete covers downloaded from Amazon after 90 days
Last modified: 2015-03-13 11:05:38 UTC
See Bug #345688 comment 21 by James "Doc" Livingston: > That sounds good. It would actually be good to record where and when > we got the [cover art] from too - since we're any art from amazon is > supposed to be deleted and redownloaded every 90 days (it's in their T&C). When the artdisplay plugin downloads a cover from Amazon, we should record the timestamp in order to delete it 90 days later. We could do this check before showing a cover, but that would slow down the cover finding. My suggestion is that we a thread running in parallel at startup to go though the "Amazon timestamps" and clear out expired covers. Possibly show a popup notification that N covers from Amazon have been removed? Potentially some users might have rhythmbox running for days at a time - but that is kind of rare. While we could automatically download replacements at the same time, it would in many ways be easier to just wait until next time that album is played. For example, the user may have aquired a cover though other channels (and saved it in the file's tag - see bug 345975, or in the file's folder - see bug 345688 ) and we may not need to.
(In reply to comment #0) > When the artdisplay plugin downloads a cover from Amazon, we should record the > timestamp in order to delete it 90 days later. Yes. Suggest storing it in .gnome2/rhythmbox/covers/$ARTIST - $ALBUM.rb-expires, using ISO 8601 date format ("%Y-%m-%dT%H:%M:%S%Z"). > My suggestion is that we a thread running in parallel at startup to go though > the "Amazon timestamps" and clear out expired covers. Better: have a very low priority thread started at plugin initialisation to put the covers into a list sorted by expiry date (removing expired covers), then have an hourly timer to remove newly expired covers. > Possibly show a popup > notification that N covers from Amazon have been removed? Nah, debug output is all that is needed here. > While we could automatically download replacements at the same time, it would > in many ways be easier to just wait until next time that album is played. For > example, the user may have aquired a cover though other channels (and saved it > in the file's tag - see bug 345975, or in the file's folder - see bug 345688 ) > and we may not need to. Yes. Also, it's bad UI if the cover image silently changes. By leaving replacements to the next play we have at least some indication here.
Wouldn't it make sense to just look at the Modified or Create Times to decide which files to delete, rather than storing the information separately?
In reply to comment 2, > Wouldn't it make sense to just look at the Modified or > Create Times to decide which files to delete, rather > than storing the information separately? The covers in the RB cache could have come from many sources other than Amazon - but we don't want to delete all of them based on date (just the ones from Amazon). We could cache the Amazon files separately, or as suggested here record some meta-data when fetching covers from Amazon.