Question about cover cache retention time

[GK-774]

myMPD caches covers in /var/cache/mympd/covercache if an album directory does not contain a cover as picture file. This works perfectly well and substantially speeds up browsing in the album view.

The documentation states: "myMPD housekeeps the covercache on startup and each day." and "You can disable the covercache by setting the covercache expiration value to 0 days."
Now what I actually would like to achieve is just the opposite, I would like to keep the cached images as long as possible (ideally "forever") to enable the fast browsing experience that the cache affords.
What is the maximum number (days) the covercache expiration value can be set?
What are the potential drawbacks (besides storage consumption) a large cache would impose?
Would a function be possible that generates cached covers in the background for all albums in the collection that don´t have a cover file?

[jcorporation]

The max covercache value is 365. I do not know any disadvantages. There can be obsolete cache files remaining if you reorganize the music directory.

I can add an option to disable the pruning of the cache.

The fastest way for accessing covers should be to place the covers in the music directory and give myMPD access to it.

[GK-774]

I see the option to disable cover cache pruning has been already added to 15.0.0 which is great.
Yes, having the covers already in the music directory is the best way and thats what I do since I use myMPD, but still I have a lot of older albums and do not want to have to through the whole collection.

Additional questions:

What timestamp is used when the housekeeping takes place? Ctime or atime? E.g. if I have 10 days set, is everything deleted that was created 10 days ago or those that have not been accessed for 10 days? I think the latter would be preferable.

Can files from the cache be deleted manually while myMPD is running or only when it´s stopped? (Example: covercache pruning disabled and a cron job that deletes files with an access time older than 90 days).

And an idea (just an idea, probably to costly to be feasible):
Ideally one would set a storage limit for the cache and housekeeping would delete those with the oldest atime once the limit is approached or exceeded. This way the most used used covers would always be cached (up to the space one can afford on the specific machine) and only the least used would need to fetched via mpd.

[jcorporation]

myMPD uses the mtime (modification time) for houskeeping. You can delete files from the cache while myMPD is running, the covercache pruning process does it the same way.

myMPD does not use atime, because atime is often disabled for performance reasons. As I know, ctime (creation time) value is not stored on linux filesystems.

And an idea (just an idea, probably to costly to be feasible):

I like the idea, but I am unsure if it is worth the work.

[GK-774]

Ok, the creation (birth) time is not stored on all Linux filesystems (on ext4, Btrfs, XFS and JFS it is and can be seen with stat) and ctime (last time the file was changed) would be identical with mtime in our case (it´s created in place and never changed, so mtime, ctime and birth are the same).
atime might be disabled (although it´s not a good idea to do this for /var, but you never know what people do) so ok, probably not good to rely on it.
Anyway, with cache pruning disabled I can do this with a cron job based on atime. Many thanks for the answers!