posted in Selfhosted

Release v3.3.0 · immich-app/immich

For those unfamiliar, Immich is a self-hosted photo and video manager, similar to Google Photos, etc.

In the short time I’ve been using Immich, they’ve already more or less addressed my main concern, which was around shared albums. Now all I really need is for the option to display select shared albums in a user’s main feed.

Some key changes from this version that I thought were neat:

We are very pleased to release the next big milestone towards better sharing: people can now be shared!

As a user you can share people with another user in your cluster group

Lastly, by allowing cross-user merging, you can now merge a face from your own assets with people shared with you from other users. This is especially helpful if you didn’t want to re-run facial recognition after joining a cluster group before. Now, after setting up bi-directional sharing, users can manually link people together.

In an effort of making Immich more joyful to use, we are introducing memories for people’s birthdays.

If it’s the birthday of a person in your library, Immich will now celebrate that with a special memory featuring previous birthdays.

After a long list of optimizations, ML is both significantly faster and uses less memory. This affects every backend, including CPU inference. However, the level of improvement varies by model and backend. Cases where certain backends (such as OpenVINO) produced wrong outputs at times should be resolved.

github.com/immich-app/immich/releases/tag/v3.3.0
enPage

Replying to @⁨LeFrog@discuss.tchncs.de⁩

I read the whole thing. This seems like standard sponsored response of not biting the hand that feeds them now that they are full time…

The entire point 3 of the user complaint is reaching really far. The one user is being toxic through the whole thread so I also get from their side not wanting to heavily engage because nothing besides divebombing immich’s entire livelihood would satisfy them it seems.

FUTO seems like a toxic company, but the thread isn’t damning. It seems like we have to keep an eye on immich. Otherwise a fork I guess…

Replying to @⁨JustEnoughDucks@slrpnk.net⁩

I agree, the thread is not damning and I also don’t think that the maintainer(s?) are bad people or whatever. But IMHO they should be called out on this “I dont want to be political” bullshit because this is basically saying “I don’t care about others as long as I am not directly affected”. This may be not their intention, but ath the end of the day this behavior enables all the Trumps and Putins in this world to do what they do in the first place.

Replying to @⁨new_otters_raft@piefed.ca⁩

I would love to not only share the people metadata but also all pictures where they are tagged.

Usecases: the grandparents always ask for pictures of their grandchildren. I do not want todo partner sharing with them, but I would be fine to automatically share all pictures that include their face. Bonus: only share pictures where a combination of people are tagged (e.g. grandparents+grandchildren)

Replying to @⁨Kirk@startrek.website⁩

You could set them up to run a Restic server for you and then do backups with that. Restic is fully encrypted, does differential backups, and can do configurable pruning. With 4 TB the initial run will take long, even locally, but it can also resume, so should work.

github.com/restic/rest-server

Rest Server is a high performance HTTP server that implements restic's REST backend API. - restic/rest-serverGitHubGitHub - restic/rest-server: Rest Server is a high performance HTTP server that implements restic's REST backend API.Rest Server is a high performance HTTP server that implements restic's REST backend API. - restic/rest-server

Replying to @⁨Kirk@startrek.website⁩

Immich has so many dirs and files that it will take hour/hours for any file-based program to walk that tree (on an HDD) in order to do a backup. I used to use rsync, syncthing, duplicity and had gotten it to about under an hour for 1TB library. The service has to be shutdown to preserve consistency of the backup. So that downtime was okay once per day. Still a heavy operation. Not great, not terrible.

Because of the above you might want to do one of the following:

  • Use snapshotting filesystem like ZFS or Btrfs. That allows to avoid the downtime as you can backup a frozen-in-time snapshot while Immich is running.
  • The above but with ZFS om both the Immich end and the backup end. That allows transferring just the delta between the new Immich snapshot and the last snapshot the backup has. This happens entirely within the filesystem so there are no file operations needed. At every point in time ZFS knows what blocks have changed between now and the previously backed up snapshot. When you ask it for that, it starts spitting data without spensing an hour figuring out what changed. That allows online backups every hour or even more frequently. The backup of my 1TB Immich instance (HDD) takes 5-10 seconds to initiate the network transfer, then it takes whatever time it takes to get to the backup machine, which is usually equivalent to transferring whatever new was stored in Immich.

So depending on how painful migrations are for you, I’d highly recommend the latter. Otherwise the former. The ZFS snapshot send strategy works for any service you may run.

Replying to @⁨avidamoeba@lemmy.ca⁩

Immich uses user/YYYY/MM folders on my setup, and I exclude any thumbnail directories from the backup too. So not many dirs/files to check for the backup software and it’s very quick.

You don’t need to shut it down, pg_dump works fine while it’s like if you want to make sure it’s a good database backup. The files side of things are fine either way.

Replying to @⁨MangoPenguin@lemmy.blahaj.zone⁩

Immich uses user/YYYY/MM folders on my setup, and I exclude any thumbnail directories from the backup too. So not many dirs/files to check for the backup software and it’s very quick.

That makes sense. I copy the whole set of data dirs so I can trivially start it after restore or start it elsewhere without extra steps. Also because this strategy works with all services so I don’t have to consider how to backup/restore each one. Makes adding new services less work.

pgdump with live file copy while the service is in active use can result in files the db doesn’t know about, or files it thinks are there that were actuall deleted. Probably can be fixed after the fact.

More generally, as a someone who’s done software for a very long time, I’ve learned that the further away I go from the happy path of a software program, the less tested it is, the more bugs there are and the poorer the edge case handling is. It’s inherent to software development with limited labour. So for backups I lean on the process kill/recovery edge case that they all must handle. Snapshot + backup from that snapshot looks like a process death to the service upon restore.

Replying to @⁨new_otters_raft@piefed.ca⁩

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

Fewer Letters More Letters Git Popular version control system, primarily for code NAS Network-Attached Storage ZFS Solaris/Linux filesystem focusing on data integrity

3 acronyms in this thread; the most compressed thread commented on today has 4 acronyms.

[Thread #124 for this comm, first seen 10th Oct 2026, 08:50] [FAQ] [Full list] [Contact] [Source code]

Hachyderm.ioImran Nazar ~ عمران نزر (@Two9A@hachyderm.io)3.05K Posts, 306 Following, 284 Followers · Front-end #typescript developer and general keyboard tapper; author of Internet RFC 7168 (Hypertext Coffeepot Control Protocol for teapots); occasional plumber, more than occasional #c64 #retrocomputing enthusiast, terrible at classical #piano. Header photo is a verdant scene looking over the landscape near Buxton, England, taken from a single-track country road.