Failed to create thumbnails

[mumu233desu]

LRR Version and OS Docker on Debian 12

Bug Details No thumbnails were generated by default, and when I regenerated them manually, regardless of whether JPEG XL was enabled or not, I got this error:

All thumbnails generated! Encountered the following errors:
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

There's no more text to show due to the small message box size, I've googled and couldn't find a solution. The thumbnail folder is writable.

Matching Logs No logs about thumbnails. Do I need to post some others?

Screenshots

[mumu233desu]

Update: shows a message when reading

Error checking Minion job status
Error

[pringleprng]

check your folder permissions

[mumu233desu]

check your folder permissions

I bond the content and thumb directory to the local folder, and it does have read&write permissions, I'd executed chmod 777 or 666 to the folder.

[ramzh]

Having the same issue. Any solution to this?

[mumu233desu]

Having the same issue. Any solution to this?

Well, I turned to Kogma after several attemps...

[Difegue]

Sorry for the delay in looking at this; Are there any errors that look like Error while generating thumbnail in your log files?
Those are what land in that report at the end of the Minion job.

It's strange that it'd just output blanks.. You can also look at the Minion console to see the result of the regen_all_thumbnails job directly.

[Dr-Evil85]

I have the same problem that´s what i get from minion

`--- args:

• /home/koyomi/lanraragi/content/thump
• 4ed235d05d053e5b2fc552ed24be0a0016793a78
• 0 attempts: '3' children: [] created: 2024-06-03T21:56:57.61356Z delayed: 2024-06-03T21:58:08.97363Z finished: 2024-06-03T21:58:09.3646Z id: '8266' notes: {} parents: [] priority: '0' queue: default result: errors:
  • | Error building thumbnail: mkdir /home/koyomi/lanraragi/content/thump/4e: Permission denied at /home/koyomi/lanraragi/script/../lib/LANraragi/Utils/Archive.pm line 166. retried: 2024-06-03T21:57:52.97363Z retries: '2' started: 2024-06-03T21:58:09.30959Z state: failed task: thumbnail_task worker: '51'`

[mumu233desu]

Sorry for the delay in looking at this; Are there any errors that look like Error while generating thumbnail in your log files? Those are what land in that report at the end of the Minion job.

It's strange that it'd just output blanks.. You can also look at the Minion console to see the result of the regen_all_thumbnails job directly.

Thanks for reply, i'll try it next Monday ;)

[Difegue]

For permission denied errors, consider placing the thumbnail folder outside of the content folder entirely instead of the default; This same issue popped up with another user whose content folder was set to drwxrwxr-x.

Normally the content folder doesn't need to be writable (that was the main impetus behind disassociating the thumbnail folder from it to begin with), but it is likely that if it tries to mkdir the thumbnail folder (because it doesn't exist yet) and you left it in the default location as a subfolder of the unwritable content dir, it'd fail.

I should probably update the dockerfile to move the thumb directory somewhere else in the container by default..

[mumu233desu]

For permission denied errors, consider placing the thumbnail folder outside of the content folder entirely instead of the default; This same issue popped up with another user whose content folder was set to drwxrwxr-x.

Normally the content folder doesn't need to be writable (that was the main impetus behind disassociating the thumbnail folder from it to begin with), but it is likely that if it tries to mkdir the thumbnail folder (because it doesn't exist yet) and you left it in the default location as a subfolder of the unwritable content dir, it'd fail.

I should probably update the dockerfile to move the thumb directory somewhere else in the container by default..

I'm sorry that my VPS just stopped due to the provider's problem last weekend, thus I can't test it recently. I'll test it as soon as the VPS is online again.

[Difegue]

I've done said dockerfile updates(thanks to #994), so I'll try tentatively closing this for now.

[jacobgkau]

I just upgraded from 0.9.0 to 0.9.1. I saw the release note about adding a bind mount to the thumbnail folder, but I already had a different bind mount set up to a thumbnail folder separate from my content directory, and I had lanraragi configured within the container to also use a non-default thumbnail folder (I had a bind mount from /home/koyomi/lanraragi/thumb in the container to /path/to/lanraragi-data/thumbnails on my host).

Reading the release announcement & looking at the Dockerfile change, I wasn't sure if I still needed to add an additional bind mount or undo my existing config. It almost sounded like the Dockerfile was now going to create a new volume and Lanraragi may or may not use that instead of the separate directory that I configured it to use.

To be safe, I just added a second bind mount from /home/koyomi/lanraragi/content/thumb that the Dockerfile expects to the same /path/to/lanraragi-data/thumbnails directory. It seemed to work-- new thumbnails are still being added to my desired separate thumbnail folder. However, Docker (or, rather, Podman) created an empty thumb directory that's now sitting in my content folder, which is supposed to be read-only for the container. I'm mainly just confused why that empty folder's there in the default location when I did add the bind mount.

Edit: Spoke too soon. While thumbnail files were created in my desired thumbnail directory after I added a new archive, lanraragi's not displaying them properly-- the "no thumbnail" placeholder still shows up for the cover page.

[jacobgkau]

~~In case it's relevant, I'm running the Podman container for Lanraragi's Docker image within a virtual machine, and that virtual machine itself has bind mounts (using virtiofs) from the actual physical folders on my NAS to the Podman "host" folders within the VM. For that reason, whenever I add a new archive, I've always needed to click the Restart File Watcher button to get Lanraragi to pick it up, because file watching doesn't work with virtiofs.~~

Edit: Ignore the stuff about virtiofs breaking file watching. The reason that doesn't work is actually because I normally access the physical folder via sshfs on my personal computer. I just tried moving a file into the content directory via sftp instead, and lanraragi picked it up automatically, but I'm still experiencing the below behavior, so I don't think file watching has anything to do with the problem.

With the current config I described above, this is the new behavior after the update:

• When I add an archive, the page thumbnails are created in e.g. thumbnails/73/730b67f4c2db94042abc0dc55d0228f6d261e711, but the cover thumbnail is not created at e.g. thumbnails/73/730b67f4c2db94042abc0dc55d0228f6d261e711.jpg like it's supposed to be.
• If I click Generate Missing Thumbnails, then the cover thumbnail is created in the expected location & it displays properly.

I'm really confused why I now have to click Generate Missing Thumbnails to manually generate only the cover thumbnail on 0.9.1, when I used to not have to do that on 0.9.0. Under what condition would Lanraragi create the page thumbnails but not the cover thumbnail when it detects a new archive?

[jmhickman]

I also have this thing where I have to click the Generate Missing Thumbnails button, on two different instances. My thumbs directory is outside of the content directory I have set on both. Once I click that button everything shows up like it should.