Thumbnails in archive overview not reliable and always freezing

[cazendium]

LRR Version and OS
Please tell which version you're running, as well as your OS and installation method. (Windows, Docker, Native)

Mac OS

Bug Details
Please detail the bug here.

Thumbnails in overview only work sometimes. When it works, it’s instantaneous. But most of the time, opening an archive will just show a spinning wheel. Nothing happens for days.

It seems larger archives or lots of pages causes it to slow down, and tasks keep becoming inactive for minions. All inactive minions are delayed for 54 years.

I can’t seem to reset the minions or any pending previous tasks despite terminating the server.

I was wondering if there is any tweaks that could benefit me. I don’t mind tweaking code, I’ve tried increasing priorities and attempts, which seemed to work but still gets frozen on larger pages again with no way to restart it.

I’ve been changing how LANraragi operates, but this has been an ongoing issue before then. I tried using a fresh VM to confirm and it’s still the same issue.

If the thumbnail pages are put in thumb directory, can’t I have the thumb pages just default to the temp ones that were extracted if minions get stuck?

Matching Logs
Post any logs you have encountered when reproducing the bug.
If possible, switch the app to Debug Mode in order to have more logs.

Screenshots
If applicable, add screenshots to help explain your problem.

[Difegue]

See #399 (comment) for a quick overview of how extracting works -- This was tweaked later down the line to generate thumbnails for every page.
See

LANraragi/public/js/reader.js

Line 723 in cb4d1f9

const thumbnailUrl = `/api/archives/${Reader.id}/thumbnail?page=${page}`;

The advantage of firing a job per page is that if the thumbnail was already generated by normal reading, we won't redo it -- although I suppose adding a lot of jobs can overwhelm the server depending on hardware.
Minion thumbnail jobs run at the lowest priority so they shouldn't prevent extraction jobs from running however.

We could run a singular job to generate all thumbnails once the archive is extracted, but that means previews wouldn't show up gradually in the overview.
(The 54 year thing is due to the Redis Minion backend being unfinished, I believe it's just cosmetic)

[Difegue]

A single job with progress reporting might be a solution for this.
https://docs.mojolicious.org/Minion/Guide#Job-progress

[Difegue]

I've implemented /api/archives/:id/files/thumbnails, which will queue a single job with progress reporting.
In a similar fashion, /api/archives/:id/thumbnail?page=${page} will no longer fire individual jobs for each thumbnail (unless no_fallback is specified; This is an API behavior change but it shouldn't break anything.)

Coupled with some efficiency changes in the Reader, it should now be easier to see the progress of the server with new thumbnails, and archives which are already fully cached shouldn't have unneeded lag.

pagethumbs.mp4