Shrink thumbnails on server side

[graue]

When displaying albums in search results, Pots, fyi downloads the full size album artwork (which in some cases can be like 1600x1600 and 3MB), only to display it as a 50x50 thumbnail.

The server should create a 50x50 version before sending, possibly at a new endpoint like /albumart/<id>/thumb.

[tippenein]

I use imagemagick to do this locally all the time.

convert cover.jpg -resize 50x50\> cover-thumb.jpg

The \> makes sure it doesn't enlarge anything which seems very unlikely, but w/e

It will add some more dependecies (imagemagick, libmagickcore-dev, libmagickwand-dev) but we can shrink the images if the libraries exist and leave them huge otherwise.

also, this reference

[graue]

Totally. I want to think about it carefully before we create any temp files. I'm thinking there should be a cache directory that holds both transcoded files and shrunken images. When a transcode or thumbnail is requested, if it's already cached, that gets sent as a static file; otherwise it's created on the fly and also saved in the cache. When the cache exceeds a total size, the file that hasn't been requested in the longest amount of time is deleted.

Do you know any readymade solutions for this? It's basically what Memcached does, but that only handles blobs up to 1 MB, big enough for thumbnails, but not for audio tracks.

[tippenein]

Redis comes to mind since that's always mentioned in the same breathe as memcached. would you actually want to hold transcoded audio in memory? Seems like storing the path to the transcoded file and the time it was created/last used would be what we want.

In this scenario, does "cached" mean the file is saved as potsfyi/cache/file-<some-hash>.mp3 and stored in some database (redis?)

[graue]

Yes, that's what I mean... a cache on disk.

[graue]

The cache dir added in 4481460 could be used for this.