Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misbehavior when using remote storage with rclone #116

Open
QtFuta opened this issue Jan 23, 2024 · 4 comments
Open

Misbehavior when using remote storage with rclone #116

QtFuta opened this issue Jan 23, 2024 · 4 comments

Comments

@QtFuta
Copy link

QtFuta commented Jan 23, 2024

I just moved my gallery to an s3 compatible storage and I mounted it using rclone, so I updated my docker compose to point to the new directory hosted in s3 instead of a local drive and when scanning new files the UI got all weird O.o.

The images before moving the data to s3 are fine, but new files look just as blank rectangles or as nothing at all.

I looked into the html, this is for the empty rectangles

<div class="fluent__cell " style="height: 277px; width: 196px; touch-action: pan-y; user-select: none;">
  <img style="height: 277px; width: 196px;" loading="lazy">
</div>

And this is for the emptiness (:astonished:), a single row for just one img element

<div class="item" style="position: absolute; top: 10112px; height: 120px;">
  <div class="fluent__row" style="height: 120px;">
    <div class="fluent__cell " style="height: 120px; touch-action: pan-y; user-select: none;">
      <img style="height: 120px;" loading="lazy">
    </div>
  </div>
</div>

Reading other issues I found how to read the DB 😅
So, here are the entries for the html above (the first one is for the rectangle, and the second for the emptiness)

{
  "id": "e664eba0e9211f0be4bf5745c46d326d07c1f617",
  "type": "image",
  "updated": "2024-01-22T23:15:22.405Z",
  "date": "2024-01-22T14:34:10.038Z",
  "files": [
    {
      "id": "e664eba0e9211f0be4bf5745c46d326d07c1f617",
      "index": "expanse",
      "type": "image",
      "size": 443999,
      "filename": "media/4df9a0e0-b933-11ee-86a0-79be5038a31e.jpeg"
    }
  ],
  "previews": [],
  "vibrantColors": [],
  "tags": [],
  "objects": [],
  "faces": [],
  "width": 2357,
  "height": 2357,
  "orientation": 1,
  "duration": 0,
  "make": "unknown",
  "model": "unknown",
  "focalLength": -1,
  "focalLength33mm": -1
}
{
  "id": "396816247a5faba3cb5e383401c9965ae7393647",
  "type": "image",
  "updated": "2024-01-22T23:15:22.405Z",
  "date": "2024-01-22T16:04:11.181Z",
  "files": [
    {
      "id": "396816247a5faba3cb5e383401c9965ae7393647",
      "index": "expanse",
      "type": "image",
      "size": 6074119,
      "filename": "media/e1642920-b93f-11ee-86a0-79be5038a31e.jpeg"
    }
  ],
  "previews": [],
  "vibrantColors": [],
  "tags": [],
  "objects": [],
  "faces": []
}

I tried the steps in here to try to fix the issue https://docs.home-gallery.org/faq/index.html#i-want-to-start-all-over-how-do-i-reset-the-gallery
But there was no difference.

There was no mention of deleting database.db so I didn't, looking at the file and seeing the records above maybe I should have deleted it.
could I just manually remove the records from the file to process them again?
I don't know what is the initial issue tho, so maybe they'll end up broken again 🤔
All new files I've tried end up like the emptiness.

Any idea what could be the issue? 😓

@xemle
Copy link
Owner

xemle commented Jan 23, 2024

Hi @QtFuta

Thank you for reaching out. I am happy that you are trying to run the gallery with an S3 backend since it should run in theory but I never tried to do so. So you are helping to find it out.

The error type sounds that exiftool fails to run on the extractor step. Depending on the exif extractir step the previews are generated. So short: No exif data, no preview, wired UI grid. Can you check your logs?

Further would you mind to paste your docker compose setting for futher inspection?

IMHO the theory with a remote docker volume via fuse is that docker requires a special security flag to work properly. Than the file access is transparent for the application like the gallery. The gallery needs read access to the media directories and read/write access to the config and storage directories.

@QtFuta
Copy link
Author

QtFuta commented Jan 23, 2024

Hi @xemle !

Thanks for the quick response 😺

Oh, I didn't know there was a need for any special configuration in docker. Not sure why I don't need it since I can access my mounts inside my containers without issue 😅

Here are the errors I've found related to the exif process, so the extractor doesn't like to wait for rclone to fetch the file hehe.
Some images are working properly, and now some old ones are also being updated if the exif process succeeds 🥳

gallery  | [2024-01-23 14:45:17.934]: extractor.image.resize Use sharp to resize images
gallery  | [2024-01-23 14:45:39.311]: extractor.image.exif warn Could not extract exif of 5d6ac9c:expanse:media/8fd02710-b9fa-11ee-a130-990b4b3ce1b7.mp4: Error: timeout: waited 5000ms
gallery  | [2024-01-23 14:45:51.740]: extractor.image.exif warn Could not extract exif of f281ab7:expanse:media/8fd0c350-b9fa-11ee-a130-990b4b3ce1b7.png: Error: timeout: waited 5000ms

gallery  | [2024-01-23 14:48:24.548]: extractor.image.preview Created 5 image previews from cb695dd:expanse:media/8fd00000-b9fa-11ee-a130-990b4b3ce1b7.jpeg with sizes of 1920,1280,800,320,128 8.2s

Probably I should be just waiting for rclone and the extractor to find the sweet spot where they work together to update the files hahaha.
Not sure how this can be an issue because I see logs of index.update properly listing the new files 🤔
index.create lasts the time it takes to download the data from s3 and I see this transfer in my quota graphs

gallery  | [2024-01-23 14:36:10.394]: cli.task.import Run incremental import in batch mode of different file sizes
gallery  | [2024-01-23 14:36:10.396]: cli.task.import Run batch import: Import files up to 20 MB
gallery  | [2024-01-23 14:36:10.399]: cli.task.import Import files from source dirs: /data/expanse
gallery  | [2024-01-23 14:36:10.426]: cli.spawn Run cli with index --directory /data/expanse --index /data/config/expanse.idx --exclude-if-present .galleryignore --max-filesize 20M --add-limits 10,20,1.2,200 --journal 0123-iOBY
gallery  | [2024-01-23 14:36:11.642]: index Updating file index for directory /data/expanse
gallery  | [2024-01-23 14:36:11.872]: index.filter.maxFilesize Limit files up to 20M (20971520 bytes)
gallery  | [2024-01-23 14:36:11.874]: index.filter.limit Index has 7514 entries. Set index limit to max 200 new entries
gallery  | [2024-01-23 14:44:53.325]: index.create Read 7550 files in /data/expanse 09:41
gallery  | [2024-01-23 14:44:53.359]: index.merge Merged 7514 entries 10ms
gallery  | [2024-01-23 14:44:53.363]: index.update Index merged of 7550 entries (36 added, 0 changed, 0 deleted) 35ms
gallery  | [2024-01-23 14:44:54.259]: index.checksum Calculating ids for 36 entries with 113.2MB of total size 20.0GB (0.6%)

For the sake of completeness, here's my docker compose 😅

version: "3.8"

services:
  # api:
    # image: xemle/home-gallery-api-server
    # environment:
      # TensorflowJS backends
      # - cpu: slowest and best support
      # - wasm: good perfromance for arm64 and amd64 platforms
      # - node: best performance on amd64 platform
      #- BACKEND=cpu
      # - BACKEND=wasm
      #- BACKEND=node
  gallery:
    container_name: gallery
    image: xemle/home-gallery:latest
    restart: unless-stopped
    stdin_open: true
    tty: true
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      - GALLERY_API_SERVER=http://gallery-api.local.dev
      - GALLERY_API_SERVER_CONCURRENT=2 # On low powered devices
      - GALLERY_API_SERVER_TIMEOUT=30 # On low powered devices
      - GALLERY_OPEN_BROWSER=false
      # Use polling for safety of possible network mounts. Try 0 to use inotify via fs.watch
      - GALLERY_WATCH_POLL_INTERVAL=300
    volumes:
      - ./data:/data
      - ./gallery.config.yml:/data/config/gallery.config.yml
      - /mnt/static_qt/expanse/:/data/expanse/
    entrypoint: ['node', '/app/gallery.js']
    command: ['run', 'server']

Here's the line in fstab to mount the remote s3:static_qt /mnt/static_qt/ rclone rw,allow_other,config=/root/.config/rclone/rclone.conf,cache_dir=/var/cache/rclone 0 0
(I did this following this guide https://rclone.org/commands/rclone_mount/#rclone-as-unix-mount-helper )

And also here's my gallery.config.yml

sources:
  - dir: ~/expanse
    excludeIfPresent: .galleryignore

@xemle
Copy link
Owner

xemle commented Jan 23, 2024

Oh, I didn't know there was a need for any special configuration in docker. Not sure why I don't need it since I can access my mounts inside my containers without issue 😅

You are mounting the S3 on the host not inside the docker container. A fuse mount in the docker container requires special flags.

Here are the errors I've found related to the exif process, so the extractor doesn't like to wait for rclone to fetch the file hehe. Some images are working properly, and now some old ones are also being updated if the exif process succeeds 🥳

gallery  | [2024-01-23 14:45:17.934]: extractor.image.resize Use sharp to resize images
gallery  | [2024-01-23 14:45:39.311]: extractor.image.exif warn Could not extract exif of 5d6ac9c:expanse:media/8fd02710-b9fa-11ee-a130-990b4b3ce1b7.mp4: Error: timeout: waited 5000ms

OK. Got it. This is a similar issue like #111. The timeout of 5sec seems to low for remote sources like your setup with S3.

I plan to increase the timeout for exiftool as configuration value. Since I am working on a UI rewrite I will increase the timeout after that.

In the meanwhile you can open a PR if you like. Maybe you can play around with the timeout value which would be good for your setting. I am interested also in video files how your setup will behave...

Probably I should be just waiting for rclone and the extractor to find the sweet spot where they work together to update the files hahaha. Not sure how this can be an issue because I see logs of index.update properly listing the new files 🤔 index.create lasts the time it takes to download the data from s3 and I see this transfer in my quota graphs

The indexer has no timeout implemented. Therefore the file indexer part works well. The problem is the extractor step with its timeouts. Maybe you can increase some cache strategies on rclone to get the initial setup right.

After finalizing your initial setup, please run a full import via ... gallery run import. Than all missing files should be recreated. In the incremental bootstrap phase only new files are processed and older broken images for the database are untouched (for performance reasons).

Further, the file indexer uses the file matcher strategy size-ctime-inode by default to identify file changes. This is not recommended for remote sources like your setup since the inodes are usually not stable and lead to new unnecessary reimports. I recommend to update your source setting to use size-ctime, depending on the fuse mapping maybe also only size. So try:

sources:
  - dir: ~/expanse
    excludeIfPresent: .galleryignore
    matcher: size-ctime

For the sake of completeness, here's my docker compose 😅

Thank you. I was hoping to have a S3/rclone mount within the container. If you plan to do that, please provide an example of your settings, that would be great.

@QtFuta
Copy link
Author

QtFuta commented Jan 26, 2024

You are mounting the S3 on the host not inside the docker container. A fuse mount in the docker container requires special flags.

Oh, got it. Then I don't think I want to go to that hazel 😅

The timeout of 5sec seems to low for remote sources like your setup with S3.

I plan to increase the timeout for exiftool as configuration value. Since I am working on a UI rewrite I will increase the timeout after that.

This is the first time I know about a timeout when handling a file.
Why have a timeout when trying to read from disk? 🤔
I was under the impression timeouts only existed when dealing with network requests, that's why I went on the route of mounting my s3, I know it's going to be slow, but I don't mind waiting, and the applications I run should deal with it as if it was a very slow drive, not a network request.
And if something fails rclone has properly thrown I/O errors to the application trying to work with the files inside s3.

That being said... There are some errors which are probably thrown because of I/O 😅
Not sure if these happened because I manually ran run import and then the container also started to run it at the same time.
(/data/storage is in an HDD with zfs, not in s3)

[2024-01-26 01:22:10.200]: extractor.image.exif warn Could not extract exif of eb3c1be:media:39/84/file_sp_42281590-bbc5-11ee-9d08-655c7e743984.jpg: Error: BatchCluster has ended, cannot enqueue -json
-struct
-fast
-*Duration*#
-GPSAltitude#
-GPSLatitude#
-GPSLongitude#
-GPSPosition#
-Orientation#
-all
/data/media/39/84/file_sp_42281590-bbc5-11ee-9d08-655c7e743984.jpg
-ignoreMinorErrors
-execute

[2024-01-26 01:22:10.465]: extractor.image.exif warn Could not extract exif of 0879bac:media:24/4b/file_sp_86dc46c0-bbe3-11ee-9027-efa2b015244b.mp4: Error: BatchCluster has ended, cannot enqueue -json
-struct
-fast
-*Duration*#
-GPSAltitude#
-GPSLatitude#
-GPSLongitude#
-GPSPosition#
-Orientation#
-all
/data/media/24/4b/file_sp_86dc46c0-bbe3-11ee-9027-efa2b015244b.mp4
-ignoreMinorErrors
-execute

[2024-01-26 01:22:11.529]: extractor.image.preview error Could not calculate image preview of eb3c1be:media:39/84/file_sp_42281590-bbc5-11ee-9d08-655c7e743984.jpg: Error: Could not calculate image preview from /data/media/39/84/file_sp_42281590-bbc5-11ee-9d08-655c7e743984.jpg with size 1920: Error: /data/storage/eb/3c/1be81e5f69f0dabe2475496a25cd3b8cc76c-image-preview-1920.jpg: unable to open for write
unix error: No such file or directory

I am interested also in video files how your setup will behave...

I added several videos, mostly short ones of about a minute, two large ones of 9minutes and 20 minutes and everything was fine 😸
The only issue keeps being the exif extraction, but if that goes well then the video conversion works properly.

I recommend to update your source setting to use size-ctime

Made the change. What should I watch for to know if something improved? 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants