Your ML model cache volume is getting blown up during restart and the model is being re-downloaded during the first search post-restart. Either set it to a path somewhere on your storage, or ensure you’re not blowing up the dynamic volume upon restart.

In my case I changed this:

  immich-machine-learning:
    ...
    volumes:
      - model-cache:/cache

To that:

  immich-machine-learning:
    ...
    volumes:
      - ./cache:/cache

I no longer have to wait uncomfortably long when I’m trying to show off Smart Search to a friend, or just need a meme pronto.

That’ll be all.

  • wabasso@lemmy.ca
    link
    fedilink
    English
    arrow-up
    4
    ·
    22 hours ago

    Ok I should know this by now, but what actually is the current “./“ directory when you use that? Is it the docker daemons start dir like /var/docker ?

      • elmicha@feddit.org
        link
        fedilink
        English
        arrow-up
        1
        ·
        11 hours ago

        I’m almost sure that ./ is the directory of the compose.yaml.

        Normally I just run docker compose up -d in the project directory, but I could run docker compose up -d -f /somewhere/compose.yaml from another directory, and then the ./ would be /somewhere, and not the directory where I started the command.

        • ohshit604@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          4
          ·
          edit-2
          15 hours ago

          As other stated it’s not a bad way of managing volumes. In my scenario I store all volumes in a /config folder.

          For example on my SearXNG instance I have a volume like such:

          services:
            searxng:
              
              volumes:
                - ./config/searx:/etc/searxng:rw
          

          This makes the files for SearXNG two folders away. I also store these in the /home/YourUser directory so docker avoids using sudoers access whenever possible.

          • SheeEttin@lemmy.zip
            link
            fedilink
            English
            arrow-up
            1
            ·
            13 hours ago

            So why would you not write out the full path? I frequently rerun compose commands from various places, if I’m troubleshooting an issue.

            • ohshit604@sh.itjust.works
              link
              fedilink
              English
              arrow-up
              3
              ·
              edit-2
              13 hours ago

              So why would you not write out the full path?

              The other day my raspberry pi decided it didn’t want to boot up, I guess it didn’t like being hosted on an SD card anymore, so I backed up my compose folder and reinstalled Rasp Pi OS under a different username than my last install.

              If I specified the full path on every container it would be annoying to have to redo them if I decided I want to move to another directory/drive or change my username.

              • SheeEttin@lemmy.zip
                link
                fedilink
                English
                arrow-up
                1
                ·
                12 hours ago

                I’d just do it with a simple search and replace. Have done. I feel like relative paths leave too much room for human error.

        • MangoPenguin@piefed.social
          link
          fedilink
          English
          arrow-up
          8
          ·
          19 hours ago

          Its convenient because your data is stored in the same folder that your docker-compose.yaml file is in, making backups or migrations simpler.

          • Avid Amoeba@lemmy.caOP
            link
            fedilink
            English
            arrow-up
            2
            ·
            16 hours ago

            Yup. Everything is in one place and there’s no hardcoded paths outside of the work dir making it trivial to move across storage or even machines.