(fix) Refactor/redesign of game artwork services

[WizardOfYendor1]

Pull Request

Summary

This is fix/refactor/redesign born out of findings during load testing I was performing. Basically I threw thousands of games at it at once, and also "burst" fed it in and discovered a leak in the preview plans. This triggered multiple full-library reconcillation passses. Thought it would be a simple fix, but then one thing led to another and finally got sick of playing whack-a-mole and ripped out the whole thing out and redesigned it.

Large ROM imports no longer degrade the server (e.g. memory). Loading a large arcade set used to leak an abandoned plan entries in a Map. Also filesystem watchers with large continuous back-to-back library scans and titles with long names blew through an artwork timeout so they timed out on every attempt and retried forever without succeeding. All three are fixed, memory is bounded, scans wait for the library to go quiet, and background artwork fetching gets the time it needs while client-facing requests getting priority. Preview selection is now iterative, resumable, and restart-safe rather than an in-memory callback chain. Systems can recover from interrupted, rejected, evicted, or stale work instead of remaining permanently blank. Cached misses are processed without a recursive async traversal, and queue growth remains controlled while guaranteeing that preview discovery continues.

Filesystem reconciliation now waits for imports to go quiet, failed watchers are recreated, and interactive requests retain a short response budget while background "pre-warming" receives enough time to finish.
Missing artwork files are detected and reopened automatically.

Worker threading was fixed such that they actually spawn multi-threads based upon a CPU core formula but caps out at 4 regardless to guard against crushing a system.

All of that, and then some, are covered by tests.

There is should be no impact on previous users. No API or protocol surface changed, so old and new clients are unaffected in both directions. The noticable effects (IF noticed) are that stuck systems can recover and imports run quieter and faster.

Related Issues

None (yet!)

Type of Change

• Bug fix
• New feature
• Refactor
• Performance improvement
• API / endpoint change
• Settings schema change
• Documentation update
• Build/CI change
• Other (describe):

Area

• Settings sync / profiles
• Admin defaults / config page
• Ratings (MDBList / TMDB)
• Notifications / Push (FCM / relay)
• Seerr integration
• Games / Emulators
• Custom home rows
• Web Client (Go to Moonfin-Core repo)
• Other / shared

Client Impact

Does this need matching changes in a client repo (Core, Smart-TV, Roku)?
API endpoints don't change, should be no impacts to existing clients

• No client changes needed
• Companion client PR(s) required, linked here:
• New setting keys added. List each key and confirm it matches the client key exactly, including casing:

Compatibility

• Change to the settings profile is additive only, no renamed or removed properties
• New properties use the same type the client sends (a client bool maps to bool?, an int to int?)
• Migration added for any renamed or removed settings
• Older clients still work, unknown fields are ignored and no keys were removed

Testing

Testing with physical devices under heavy load scenarios and generally doing stupid stuff like deleting artwork directories from the plugin server storage etc.

• Built the plugin and deployed to a Jellyfin server
• Verified against a live client (which one:) Shield and Fire Cube
• Manual testing completed
• Not tested (explain why):

Screenshots (if applicable)

N/A

Checklist

• Code builds successfully
• Code follows project style and conventions
• No unnecessary commented-out code
• No new warnings introduced
• Any new setting keys match the client-side keys exactly

[github-actions]

Build Successful

The plugin compiled successfully against .NET 8 / Jellyfin 10.10.0.

Property	Value
Commit	a4f6d40
Workflow	Build #357