ejurgensen/forked-daapd — pull request #44 by chme (2014-08-03 06:15:01+00:00)
Title: wip: add caching of artwork images

This pr adds caching of artwork images to forked-daapd. This is far from being complete, but i want to get some early feedback on this.

I am running forked-daapd on the rpi with the mp3s stored on a nas. Sometimes the response time of forked-daapd to requests issued from the remote takes several seconds, which is sometimes annoying. I found one (maybe the main) reason is, that artwork images are always read from disc and rescaled. As the remote app requests several images in parallel when showing the album or artist list, all these requests need to be handled before another command can be processed (requests from remotes are queued and one after the other is processed in httpd.c).

The idea is to store the rescaled images in a database table on first request, so subsequent requests for the same image (with the same max width/height) only need to access the database.

In the current state, this pr adds the caching-tables to the songs3.db (new db version 16) and stores the rescaled image for each item or group and each requested max height/width. There is currently no handling for deleting items from the cache.

Some things that are missing:
* a possibility to clear the whole cache
* if a file (song or artwork) changes (change/delete/new) update the corresponding cache entries
* do not store duplicates if two songs share the same artwork

I am not sure if using the same database for the library and the artwork cache is good. Using a separate database for the artwork cache has some advantages, e. g. deleting the db file would clear the cache and caching would only be enabled, if the database path is set in the config file.

In my tests the response times of forked-daapd significantly improve with caching artwork.