LANraragi Using Experience

Posted on In , , Word count in article: 962 Reading time ≈ 3 mins.

Preface

I have been using LANraragi for a while and encountered some issues. I managed to resolve them, and I thought it would be a good idea to document my experience in a post. You can refer to my previous article on installing LANraragi first.

Issue 1: Mounting Thumbnail Directory Causes Thumbnail Generation Failure

When installing LANraragi, to ensure the content directory is read-only, I set the thumbnail directory as an internal path of the container. This means that every time I deleted and restarted the container, thumbnails will be regenerated. This practice not only wasted computational resources but also deviated from Docker’s best practices. To address this, I used a new volume to store the thumbnails.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
version: "3"

services:
  lanraragi:
    image: difegue/lanraragi:v.0.9.0
    container_name: lanraragi
    volumes:
      - /mnt/hgfs/doujinshiArchives:/home/koyomi/lanraragi/content:ro
      - lanraragi-database:/home/koyomi/lanraragi/database
      - lanraragi-thumbnail:/home/koyomi/lanraragi/thumb
    restart: unless-stopped
  
volumes:
  lanraragi-database:
  lanraragi-thumbnail:

lanraragi-thumbnail is the volume for storing thumbnails.

After starting the container, I noticed that thumbnails could not be generated. Upon entering the ‘Minion Console’, I found the following error:

image-20240220111456968

Why did mkdir not have permission? I entered the container:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/home/koyomi/lanraragi # ls -lah
total 192K   
drwxr-sr-x    1 koyomi   koyomi      4.0K Feb 20 02:14 .
drwxr-sr-x    1 koyomi   koyomi      4.0K Feb 20 02:14 ..
-rw-r--r--    1 root     koyomi        52 Oct 29 21:19 config.log
drwxrwxrwx    1 root     root       16.0K Feb 17 11:44 content
drwxr-xr-x    3 koyomi   root        4.0K Feb 20 03:10 database
drwxr-sr-x    3 koyomi   koyomi      4.0K Oct 31 00:58 lib
drwxr-sr-x    2 koyomi   koyomi      4.0K Feb 20 02:14 log
-rw-r--r--    1 koyomi   koyomi       186 Oct 31 00:58 lrr.conf
-rw-r--r--    1 koyomi   koyomi         8 Feb 20 02:14 oshino
-rw-r--r--    1 koyomi   koyomi     97.6K Oct 29 21:02 package-lock.json
-rw-r--r--    1 koyomi   koyomi      2.1K Oct 27 23:07 package.json
drwxr-sr-x    1 root     koyomi      4.0K Feb 20 02:14 public
drwxr-sr-x    2 koyomi   koyomi      4.0K Oct 31 00:58 script
drwxr-sr-x    3 koyomi   koyomi      4.0K Oct 31 00:58 templates
drwxr-sr-x    4 koyomi   koyomi      4.0K Oct 31 00:58 tests
drwxr-xr-x  257 root     root        4.0K Feb 20 02:19 thumb
drwxr-sr-x    1 koyomi   koyomi      4.0K Oct 31 00:59 tools

Note the thumb directory created by the root user, but the user running LANraragi, koyomi, does not have write permission to that directory. Just granting permission:

1
chmod 777 thumb

Then, in ‘Tags and Thumbnails’, click on ‘Generate Missing Thumbnails’.

It’s also worth noting that the default manga directory, content, has elevated permissions intentionally set by the author. Therefore, using content/thumb as the default thumbnail directory will not cause this issue.

Issue 2: Real-Time File Monitoring Failure

Refer to the ‘Background Workers’ in the settings:

This File Watcher is responsible for monitoring your content directory and automatically handling new archives as they come. If Shinobu is dead or unresponsive, you can reboot her by clicking this button.

While it should monitor file changes in real-time, I couldn’t use this feature. The reason is that this feature utilizes the inotify API:

The inotify API provides a mechanism for monitoring filesystem events. Inotify can be used to monitor individual files, or to monitor directories. When a directory is monitored, inotify will return events for the directory itself, and for files inside the directory.

If the file system does not support this API, obviously, LANraragi cannot monitor file changes.

I use VMware’s shared folder to map manga resources to Linux, and the underlying file system of the shared folder does not support inotify.

Solution: Click ‘Restart File Watcher,’ which will scan the entire content directory after restarting. Alternatively, write a scheduled task script to POST /api/shinobu/restart.

In fact, many software applications use inotify to monitor file changes, making this a common issue.

My Jellyfin media folder also uses VMware’s shared folder, so it faces the same problem. However, Jellyfin is more popular, which allowed me to find the cause to this issue quickly from related posts. More importantly, Jellyfin explicitly states that only file systems supporting inotify have this functionality, which is a good practice for other software authors to follow when documenting.

Real Time Monitoring

This will let Jellyfin automatically update libraries when files are added or modified. Unfortunately, this feature is only supported on certain filesystems.

For Linux systems, this is performed by inotify. NFS and rclone do not support inotify, but support can be provided by using a union file system such as mergerfs with your networked file systems.

By the way, here’s the solution for Jellyfin:

  • Increase the frequency of the scheduled task ‘Scan Media Library’ – this task doesn’t consume many resources, so running it frequently is not an issue.
  • Execute a refresh through the API.

Gains

This script is quite useful:

image-20240220131323937

My manga directory structure is:

1
2
3
4
5
6
├── Author1
│   ├── Manga Archive 1
│   └── Manga Archive 2
└── Author2
    ├── Manga Archive 1
    └── Manga Archive 2

This script categorizes the corresponding manga into a specific author’s category. Although I did not (and will not) tag manga, using author as a category achieves the same effect, allowing me to select manga based on the author.

References