Hi guys! I’m having my first attempt at Immich (…and docker, since I’m at it). So I have successfully set it up (I think), and connected the phone and it started uploading. I have enabled foreground and background backup, and I have only chosen the camera album from my Pixel/GrapheneOS phone. Thing is, after a while (when the screen turns off for a while, even though the app is unrestricted in Android/GrapheneOS, or whenever changing apps…or whenever it feels like), the backup seems to start again from scratch, uploading again and again the first videos from the album (the latest ones, from a couple of days ago), and going its way until somewhere in December 2023…which is where at some point decides to go back and re-do May 2024. It’s been doing this a bunch of times. I’ve seen mentioned a bunch of times that I should set client_max_body_size on nginx to something large like 5000MB. However in my case it’s set to 0, which should read as unrestricted. It doesn’t skip large videos of several hundreds megs, it does seem to go through the upload process…but then it keeps redoing them after a while.

Any idea what might be failing? Why does it keep restarting the backup? By the way, I took a screenshot of the backup a couple days ago, and both the backed up asset number and the remainder has kept the same since (total 2658, backup 179, remainder 2479). This is a couple of days now going through what I’d think is the same files over and over?

SOLVED: So it was about adding the client_max_body_size value to my nginx server. I thought I did, so I was ignoring this even though I saw it mentioned multiple times. Mine is set to value 0, not 50000M as suggested on other threads, but I thought it should work. But then again, it was in the wrong section, applying to a different service/container, not Immich. Adding it to Immich too (with 0, in my case, which should set it to “unlimited”) worked immediately after restarting nginx service. Thanks everyone for all the follow ups and suggestions!

  • blotz@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    6 months ago

    I think the issue might be that the config changes haven’t been properly committed. Docker container won’t just update based on docker compose config.

    docker container stop
    docker container rm
    

    You might want to delete and reset any settings which have been set

    docker volume ls
    docker volume rm (IDs from docker volume ls)
    

    (This will also wipe out any backups/accounts made on immich already tho)

    But once you have deleted the old containers, running docker compose up -d will start the containers with the new config. You can use docker compose logs -f to see the server logs and check if everything is working.

    • iturnedintoanewt@lemm.eeOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      6 months ago

      Thanks for all the help. I changed the paths as I was mentioning a bit on the .env, so they matched the ones on the docker-compose.yml. But no dice. I think it gets stuck at the same picture, although I’m not 100% sure which one. After I rebuilt the container, the number of assets increased by two, but I also realized that I took a couple pics earlier. So it added those two and crashed a while later at the same spot as before…Is a picture/video capable of corrupting the whole backup?? Also, I’m not sure how to properly track which one is messing it, because the backup seems to have skipped a lot of pictures in what it copied.

      • seang96@spgrn.com
        link
        fedilink
        English
        arrow-up
        1
        ·
        6 months ago

        If it is due to a sigle asset I imagine an error would log to the console.

        • iturnedintoanewt@lemm.eeOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          6 months ago

          O.M.G…so many hours wasted. One of my first searches already returned “you should increase client_max_body_size to something like 50000M”, and I was like I aLreAdy iNCreAseD mY client_max_body_size tO zERo sO its uNLimIteD DuH <spongebob.jpg> Well turns out my client_max_body_size 0 parameter was in a section defining parameters for a different container/server. So of course it wasn’t applying to Immich. Just added the same line to Immich section too, restarted nginx…and the backed up asset count is already wayy ahead of the ceiling it would always hit at 180ish assets. I think I might have found my issue.

          Thanks for all the help and following up!

          • seang96@spgrn.com
            link
            fedilink
            English
            arrow-up
            1
            ·
            6 months ago

            Glad you found the issue! I fell asleep hard last night sorry I couldn’t be your rubber duck haha

        • iturnedintoanewt@lemm.eeOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          6 months ago

          You mean to docker logs immich_server ? I think this would be about the only error kinda it’s outputting once in a bluemoon.

          [Nest] 6 - 05/29/2024, 2:40:17 PM WARN [ImmichServer] [ExpressAdapter] Content-Type doesn’t match Reply body, you might need a custom ExceptionFilter for non-JSON responses

          Everything else is Websocket Connect, Websocket Disconnect.