Persistent metadata + image cache (the pattern the other *arr apps use)

[Paelsmoessan]

The problem in one sentence

Right now, every time you open or refresh the library, Listenarr goes back out to the internet to
fetch cover art and metadata again, instead of keeping its own local copy.

That works with a handful of books, but it doesn't scale:

• It's slow. Opening the grid fires one live request per visible cover, hundreds on a big library.
• It can get you blocked. Hammering Audible/Audnexus and image hosts over and over is exactly what
  triggers rate limits or bans.
• It forgets everything. If a cover doesn't exist, or a lookup already succeeded a minute ago,
  there's no memory of it, so the same work happens again on the next refresh. (We recently hit a
  nasty version of this in Fix AudiobooksView freeze/leak and uncacheable cover 500s #731: a broken code path returned an error that browsers refuse to cache,
  so the app re-requested it on every single screen redraw.)

How the other *arr apps solved this (checked against their actual source code)

They keep a local copy so they don't re-fetch from the internet each time. Two parts:

1. Cover images, the "MediaCover" approach (Sonarr / Radarr):

• Download each cover once and save it in a local MediaCover folder (one subfolder per item).
• This happens when a book is added or refreshed, not the first time you happen to scroll past it.
• They also make smaller resized copies (for example a 500px and a 250px version) so the grid loads a
  small image, not a giant one. They resize with the ImageSharp library.
• Those files are then served straight from disk, with no re-download and no re-resize.
• One thing they don't do well: if a cover fails to download, they just try again next refresh.
  There's no "remember that this one has no cover." That's a known annoyance (see Radarr issue #5711),
  and it's something we could actually do better than they do.

2. Metadata, a shared "middleman" server:

• Instead of every user's app hitting the original source directly, the app talks to a caching server
  that sits in the middle: Sonarr uses SkyHook (for TheTVDB), Radarr uses api.radarr.video (for TMDB),
  Lidarr uses api.lidarr.audio (for MusicBrainz).
• That middleman caches and cleans up the data, hides the API keys, and protects everyone from the
  original source being slow, rate-limited, or changing.
• Worth knowing: Readarr (the book cousin of these apps) was shut down because its book
  metadata "became unusable." Books and audiobooks are the hardest kind of metadata to keep working,
  so having a solid caching layer here isn't a nice-to-have. It's what keeps a project alive.

Where Listenarr is today

It fetches covers on demand and resizes them one at a time as they're requested; it looks up metadata
per request; and it doesn't remember misses. The good news: the app can already ask the server for a
small, grid-sized copy of a cover (built with ImageSharp, the same library the other apps use), so
we're partway there. The piece that's missing is keeping a durable local copy instead of redoing the
work every refresh.

Proposal

First (local, easy win): keep a proper on-disk cache of covers. Download and resize each once,
save it, serve it from disk, and remember when a cover doesn't exist so we stop retrying it. Warm
it up in the background so the grid is instant. This builds straight on the thumbnail work already in
place.

Later (bigger): a caching middleman for metadata, like the other apps use, so metadata isn't
re-fetched by every user on every refresh.

Questions

• Is there interest in this, or an existing plan already?
• Start with the local image cache (quick, self-contained) and consider the metadata middleman
  later?
• Any constraints to keep in mind (disk space, offline use, self-hosting)?

Happy to prototype the local image and "no-cover" cache if there's appetite.

[Paelsmoessan]

Opened a working prototype as a draft PR: #733.

It covers the image side end to end:

• the server can build and hand back a small, grid-sized copy of a cover instead of the full image,
• it remembers when a cover doesn't exist (a small sidecar database, ImageCache.db, so no change to the main DB) instead of re-checking every refresh,
• and a background job builds all those small copies ahead of time, so covers are ready before you open the page.

Running on a ~950-book library, that background job rebuilt the full set in about 7s with no browser involved.

It's a draft for feedback, not a merge request. Happy to align the details with whatever you'd prefer here, and a metadata (non-image) cache would be a natural follow-up.