Nice. So this model is perfectly usable by lower end x86 machines.

I discovered that the Android app shows results a bit slower than the web. The request doesn’t reach Immich during the majority of the wait. I’m not sure why. When searching from the web app, the request is received by Immich immediately.

Scary indeed.

This one could be helped by always using this pattern whenever you write a function that returns a value, in any language, along with no early returns:

int func(...) {
    int result = -1;
    ...
    return result;
}

I always start with writing my result default value, ideally indicating failure, and the return line. Then I implement the rest. We often don’t have the luxury of choosing the language we work with that has the features we like, but consistently enforced code style can help with a lot of problems. Anyone can make mistakes like the one in this bug regardless of experience so every little bit helps.

Well, you gotta start it somehow. You could rely on compose’es built-in service management which will restart containers upon system reboot if they were started with -d, and have the right restart policy. But you still have to start those at least once. How’d you do that? Unless you plan to start it manually, you have to use some service startup mechanism. That leads us to systemd unit. I have to write a systemd unit to do docker compose up -d. But then I’m splitting the service lifecycle management to two systems. If I want to stop it, I no longer can do that via systemd. I have to go find where the compose file is and issue docker compose down. Not great. Instead I’d write a stop line in my systemd unit so I can start/stop from a single place. But wait 🫷 that’s kinda what I’m doing isn’t it? Except if I start it with docker compose up without -d, I don’t need a separate stop line and systemd can directly monitor the process. As a result I get logs in journald too, and I can use systemd’s restart policies. Having the service managed by systemd also means I can use aystemd dependencies such as fs mounts, network availability, you name it. It’s way more powerful than compose’s restart policy. Finally, I like to clean up any data I haven’t explicitly intended to persist across service restarts so that I don’t end up in a situation where I’m debugging an issue that manifests itself because of some persisted piece of data I’m completely unaware of.

Let me know how the search performs once it’s done. Speed of search, subjective quality, etc.

I think I lost neurons reading this. Other commenters in this thread had the resilience to explain what the problems with it are.

GlobalFoundries trying to become AMD again. 😁

I use a fixed tag. 😂 It’s more a simple way to update. Change the tag in SaltStack, apply config, service is restarted, new tag is pulled. If the tag doesn’t change, the pull is a noop.

Let me know how inference goes. I might recommend that to a friend with a similar CPU.

Because I clean everything up that’s not explicitly on disk on restart:

[Unit]
Description=Immich in Docker
After=docker.service 
Requires=docker.service

[Service]
TimeoutStartSec=0

WorkingDirectory=/opt/immich-docker

ExecStartPre=-/usr/bin/docker compose kill --remove-orphans
ExecStartPre=-/usr/bin/docker compose down --remove-orphans
ExecStartPre=-/usr/bin/docker compose rm -f -s -v
ExecStartPre=-/usr/bin/docker compose pull
ExecStart=/usr/bin/docker compose up

Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

Did you run the Smart Search job?

That’s a Celeron right? I’d try a better AI model. Check this page for the list. You could try the heaviest one. It’ll take a long time to process your library but inference is faster. I don’t know how much faster it is. Maybe it would be fast enough to be usable. If not usable, choose a lighter model. There’s execution times in the table that I assume tell us how heavy the models are. Once you change a model, you have to let it rescan the library.

Check your Syncthing settings. It’s a very reliable piece of software. Other than that Immich, but that’s a slightly different use case.

Yes

I switched to the same model. It’s absolutely spectacular. The only extra thing I did was to increase the concurrent job count for Smart Search and to give the model access to my GPU which sped up the initial scan at least an order of magnitude.

Oh, and if you haven’t changed from the default ML model, please do. The results are phenomenal. The default is nice but only really needed on really low power hardware. If you have a notebook/desktop class CPU and/or GPU with 6GB+ of RAM, you should try a larger model. I used the best model they have and it consumes around 4GB VRAM.

Would this work with a public dynamic DNS?

Use low power radio like ZigBee or Z-Wave, exclusively, unless you have a good reason to trust the device.

No issues with Debian / Ubuntu on many laptops since early 2010s, mostly with Intel graphics. I had a Vostro 1400 with Nvidia and it also resumed fine, but that was 2009-11 so the experience with the Nvidia driver from that time is likely irrelevant.

Seeking profit above all else isn’t human nature. Humans have lived and still live in societies that don’t do this. The socioeconomic system that we find ourselves in currently in a large part of the world does put profit above all else. But this system is just one iteration of how we live. And even it has changed over time where it has gotten worse over the last 50 years. It too would change and likely be replaced by another in the long run. Many believe that would be some form of socialism. Or we could go largely extinct before we abandon it. A better world is possible though.

Qobuz