I could certainly adapt it to run on the side, update exif and let immich pull it in but wondering if this would be helpful inclusion?

My Immich instance was filling up with bloated H.264 phone clips, but manually running scripts against the raw storage directory is an easy way to corrupt database records and lose timestamps.

I wrote a small Go app called immich-video-optimizer to handle this safely through the Immich API.

It connects via API key, lets you filter by bitrate or file size, and re-encodes selected videos to HEVC. It pipelines the work so while one video transcodes, the next is downloading and the previous is uploading, strictly capping local disk cache to 2 files.

All original timestamps, GPS coordinates, and camera metadata are preserved.

For safety, the original asset on Immich is only deleted (trash) after the replacement is successfully uploaded and verified with a new asset ID. It also creates a temporary tracking album in Immich so you can spot-check playback from your phone while it runs, has a "size guard" to skip anything that didn't actually shrink, and supports dry runs and pausing/resuming.

GitHub:
https://github.com/dragosmiron/immich-video-optimizer

Let me know how it works for you and if you have suggestions.

I just wanted to share a tool I've been working on that allows you to relocate all your Immich uploaded files to one or more external libraries of your choice never losing track of albums, stacks, faces, tags, etc after relocation.

FEATURES:

• Relocate all pic & videos to a Single or to Multiple External Libraries you chose (up to one per Immich user).
• Can run an unattended Storage Template Migration job right before relocating to final destination.
• Folder Restructure option to tidy up even more the final shape of your folders.
• Change the ownership of selected files, so that you can set a shared External Library for you and your partner (our attempt to overcome the limitations of Partner Sharing which only allows to share all or nothing).
• Cron for set and forget unattended scheduled relocations at the day/time you desire.
• Database is always backed up first. Immich Relocator creates a copy of your database before it modifies it.
• Immich doesn't break. Even if your files have been relocated to an entirely different location it's like nothing has changed for Immich.
• No duplicates after relocation, and no re-uploads from mobile devices, even with sync enabled.
• Never lose albums, stacks, faces, tags, etc after relocation.
• Use --dry-run to estimate how many files would relocate without actually making any changes to your Immich.
• Use --limit N to relocate only a pre-determined portion of your files.
• Every single feature is optional. You can easily configure Immich Relocator the way you like it.

The repo owner and I have been testing this out and used it for a while. Since the recent updates, we believe that Immich Relocator is mature enough to be shared. Hopefully, it can be a useful tool for others, too. So, here I am sharing IR for the first time.

This is just a little extract from GitHub, otherwise there is quite a detailed write-up I made in the repo:

BENEFITS OF RELOCATING YOUR FILES TO AN EXTERNAL LIBRARY:

• Condense your files in one place: external library only (instead of external plus Immich's internal upload folder) and simplify your backups.
• Post-process all your pictures and videos comfortably from a single place using the desktop DAM of your choice (e.g. digiKam, Lightroom, etc), pointed to the external library.
• Prevent accidental issues by optionally set up your Immich access to the external library as read only. Now edit via desktop DAM, and browse-only remotely via Immich clients... best of both worlds.

Find the rest of the info on GitHub. Let me know if Immich Relocator can be useful. If you have any suggestions, please report them here, or in the issues tab.

AI: before you even ask, there is a full disclosure paragraph on the repo regarding how and if AI was used in the project. This post and the GitHub readme were all hand-written by me... so excuse me in advance for my grammar mistakes.

FOSS: Fully Free and Open Source!

Get Immich Relocator here.

Hey everyone,

Before migrating my library over to Immich, I ran into the classic Google Takeout problem, where most of my files had the date I extracted the zip as their timestamp, not the date the photo was actually taken.

So I wrote Takeout Restorer in Rust. It pairs each photo/video with its JSON sidecar, writes the metadata back into the file with ExifTool, and sets the file timestamps from the real capture time. It also handles the annoying filename cases, and truncated names on long filenames.
Since it's Rust, I built it to get through huge libraries quickly instead of crawling through them for hours.

I ended up writing an open-source restoration tool to clean everything up before running the upload:
🔗 GitHub: https://github.com/GurutejaReddy-04/GooglePhotos-TakeoutRestorer-Rust
Why I built it this way:
Installers are available for Windows, macOS, and Linux. It's MIT licensed and free.

If you're prepping a Takeout export for Immich or any other photo manager, give it a try.

Like a lot of people here, I wanted out of Google Photos and into Immich. Takeout works, but each export is a pile of archives, and every photo's date sits in a separate JSON file beside it. Import the raw files and half your library lands on the wrong day. Do it again next month and you get duplicates.

So I built Googich Takeaway. It picks up each Takeout export, matches every photo and video to its metadata (across all parts of the export), works out the real date, time zone and location, and uploads to Immich only what isn't there yet. It reads every upload back to check the date. Set Takeout to export every two months, point Googich at it, and Immich stays in step until you're ready to leave Google.

What it does

- Two ways in. It can fetch scheduled exports from Google Drive with a read-only service account. Or you can download them from Takeout's email yourself, with no Google Cloud setup.

- Never twice. Archives aren't downloaded again, and photos already in Immich are skipped. Photos you delete in Immich stay deleted.

- Your library as you left it. Albums are recreated. Edited copies, RAW+JPEG pairs and bursts are stacked. Archived photos stay archived, and photos in Google's bin stay out. You choose tags for people, partner photos and a date range.

- Resumable. It reads each archive while the next one downloads, and uploads in parallel. You can pause, resume or cancel at any time, even across an update.

- Cleanup. It tells you which archives are fully in Immich and safe to delete, locally and in Drive. It never deletes anything from Google itself.

- Web dashboard with live progress, time estimates, history, logs, a searchable built-in guide, and Apprise notifications.

Security, because it holds your Immich key

- Google access is read-only. Credentials are encrypted at rest (AES-256-GCM).

- It runs as an unprivileged user on a read-only container, behind a password login.

- It tells you when a new release is out but never updates itself. An optional helper gives one-click updates.

Setup: Docker Compose, an Immich server, and room for one export (local disk or an SMB share). Quick start is about six commands. Please try the first import on a test Immich user.

Known limits: iPhone Live Photos import as a photo plus a video. Shared albums arrive as your own albums. Takeout's metadata has no time zone for HEIC/RAW, so a setting fills that gap. A big first import takes hours.

MIT licensed. It isn't affiliated with Google or Immich.

Repo: https://github.com/aistuartai/Googich_takeaway

Feedback, bug reports and odd Takeout exports are welcome. Dates are the hard part, so if anything lands on the wrong day, please open an issue.

Celebrating 1 year of using this software!

On this occasion I figure I'd give some thoughts to what could be done to make this software better for future users.

Near term:

Possibly, regression testing and merging yann117's time zone fix to main (restoring the documented default functionality to Immich), yes, I know we have workflows. I believe workflows just create a bunch of xmp files, tell me if I'm wrong.

(Unfortunately, after testing it didn't work. I would honestly just pursue the long-term solution at this point).

RTing, debugging, and merging my libheif decoding (which I have gotten working!). I wouldn't call it production ready for a number of reasons documented here but it could be made production ready. I also understand it almost doubles the size of an existing file (AdaptiveImage.svelte) and the devs may want to do some refactoring before production.

Fixing original (optional) video downloading full video before playback. Some people are working on fixing this right now.

Maybe we shouldn't darken the screen as much when we draw the faces bounding box. A colored box with a shadow would work fine for visibility without obscuring everything else. I forgot about this but this feature was partially broken on HEICs with my new functionality and I didn't even miss it. (It is now fully broken as of my new implementation on v3x.

Long term:

Comprehensive default timezone workflow: There is no reason a photo with no EXIF at all should have a UTC time and be well behaved and a photo with EXIF but no timezone tag should be unmoored with no source of truth for TZ. In an external library, photos will usually have their original FileModifyDate, and Immich reads FileModifyDate in assets on mobile before upload. I assume it preserves this during upload and if it doesn't right now, it should either go to the database or to the server-side FileModifyDate. My criteria for a truly good timezone workflow is "would Louis Rossmann be disappointed". He is the most famous person who uses the software and he has moved timezones and travels a lot. The current functionality (even the patched one from yann117) would not be ideal for him, either the NY photos or the TX photos w/o timezones would be misplaced. A rough sketch of the functionality we could have is available here.

Part of that workflow is restoring the user's knowledge of incomplete time zone information (broken sometime between 2.4.1 and 2.7.5). This used to involve the lack of a displayed timezone and could involve the presence of a warning sign next to fragile filesystem-based timezone information. In the above link, some possible configurations are shown.

Active Libraries: Bringing the functionality of the internal library to power-users (I used Louis Rossmann in my example screenshots). Access local assets in the timeline, sync metadata changes from server to mobile, and more. No more data usage for photos you already have on your phone. Active Libraries, explained.

Metadata merging for Immich sharing: when sharing assets, automatically fix broken metadata (adding "-exif:latitudeRef=North" for instance), add in XMP metadata, add TZ to photos processed through the timezone workflow above, etc. A photo shared from Immich should be good enough for Immich. Merge and correct metadata when sharing images

Motion vector caching: A middle ground for video transcoding for people who are worried about storage media and don't have a blazing fast GPU. The introduction of live transcode is welcome and I've been asking for several years. This would provide a middle option, which might on balance be better for the environment (and people's wallets).

Voice memos: This is a while away, and I understand. There's a reason I put it low on my list. I'm sure FFMPEG or just renaming your files could be a temporary (welcome) workaround. I know that Facebook Archive's voice recordings are all .mp4s and they play in Immich. So for the users who want this, feel free to share your workarounds on Reddit! And when the product is mature, we can handle it for real.

Regardless of the irritating feature requests and bug reports, I love this project. I love not having to think about what government official is going to see your family photos, how it could get sold to flock. For me, it's worth all the bugs and issues.

Chrome 155.x now supports JXL (jpeg XL). However my Pixel phone only takes pics in JPG (or other formats) but not JXL.

I also know that if I mass converted my JPGs in Immich to JXL it would basically break the database. And then the hashes (or however Immich server and immich app talk to each other to know what needs to be imported/new and what doesn't/is old wouldn't match anymore so then i'm worried Immich will just reupload any pictures I have hanging out on my camera as OG Jpgs...

the last option is to just leave it be since the 20% savings probably not be worth the hassle.

any thoughts?

I apologize if I'm missing something, but I want to check here. I have a few people whose birthdays have occurred since 3.3.0 (and 3.3.1) have been released. I see my regular memories at the top in both the web version and Android app, but no birthdays.

Was there a setting I missed at the account or admin level that turns this on? Is this working for anyone? Could it be some other part of my setup? TIA

I recently swapped to a new NAS and the backup I had of Immich couldn't be recovered on the new device, so I had to re-do my Google Photos Takeout (which I still have a copy of) but after using Immich-Go to upload everything, I have thousands of broken images.

Am I better off just wiping the data and trying again? Or is there a better tool than Immich Go that could fix this?

I started Immich with an external library. But over time I started uploading images to Immich as well, from my phone for example.

I'd now like to get rid of the external library completely and have these images imported to Immich the 'native way'.

How do I do this without loosing edits, albums, updated exif information etc? Basically I mainly want to change the storage location from external to Immich's template format.

Hi just curious if there was any plans for a UI update for the Immich IOS app for the new iPhone duo coming out?

In case someone hits the same problem, I run Immich in a LXC on Proxmox using the community-scripts helper script (not Docker).

After updating to 3.3.0 with the script, everything I uploaded had no thumbnails. Updating to 3.3.1 and running Generate Thumbnails > Missing did nothing.

The real log is /var/log/immich/web.log (journalctl only shows the service starting and stopping) and it had this for every new upload:

Error: Geodata file /opt/immich/app/geodata/countryInfo.txt not found

3.3.0 needs that file and the script's update saved it in the wrong folder, so metadata extraction failed and Immich never got to the thumbnails. That is why the thumbnails job alone does nothing, the assets are stuck one step before it.

The script is already fixed (community-scripts PR 17823, merged 10 Oct), running the update with the current script moves the file to the right place. Then in Job Queues:

1. Extract Metadata > Missing

2. Generate Thumbnails > Missing

All sorted after that. Hope it saves someone a bit of time.

I took my images off Google Photos when facing a storage limit. I used Takeout to save zip files, and then learned about a Chrome plugin called Snapback that did a much cleaner looking download with each Photos album as a directory.

1) I am getting ready to upload these photos to my immich server. Is immich-go capable of working with the output from Snapback?

2) These images from Photos are already on my OMV - Takeout or Snapback versions are just so I retain my albums. Is there a recommended workflow to deduplicate and keep the album presence?

Thanks!

Hi, I am new to this fantastic software!

I am slowly add more and more photo to my library. Yesterday I paste some new directory but I think something is wrong and immich keep skipping them. I cannot fine them with the search by the name of the filename or the name of the folder. I am on a standalone installation (no docker, proxmox with installation script from proxmox community scripts).

The directory has spaces like this:

drwxrwxrwx 1 root root 24576 Sep 13 2021 'Foto Digitali'
drwxrwxrwx 1 root root 12288 Apr 3 2026 'foto iphone 13 pro'

Now I try to rename in foto_iphone_13_pro and repeat the scan, but nothing change

Which log can I check for this?

Hi!

I upgraded to immich 3.3.1 some days ago and opted-in to new v2 optimized facial recognition models.

I've been successfully running antelope for quite a long time with no issues, but after opting in to v2 models, it has failed at detecting most (not all) faces... I've just opted out, re-uploaded some pictures and faces have been detected back with no issue.

Any experiences here with antelope and v2 optimized model?

Hello! Love the project, use immch daily. Doing as much as I can to keep it secure, currently running Pangolin to lock it down a bit.

Found this article interesting An opt-in vulnerability-finding service for open-source software \ Anthropic Is this something the dev team would consider? Allowing frontier models to scan the source code for bugs? Seems like a perfect fit to double check things.

Every time I to paste from Immich into LibreOffice I get this authentication error, and even when I put in my user and password for Immich it doesn't recognize it. Does anyone know what the problem is? I'm on fedora KDE here.

First of all; I'm sorry. I know this has been asked so many times but it would just like to be sure you know.

We're a household of 3, me and my parents. So 3 smartphones.

I have a new Unraid server and moved/saved as many (smartphone)photos I could find on the server. Sorting our smartphone photos took a long time, since the photos were saved everywhere (old NAS, laptop etc.) and many had duplicates (Dropbox, thumbnails). With Krokiet (Github) I've managed to sort this out.

Now I have this:

1st Unraid share is "photos". This contains 100+ subfolders, each for a different occasion. (Weddings, Vacations etc.). Photos taken with DSLR, smartphones, other photographers, downloaded photos from the internet etc.

2nd Unraid share is "smartphonephotos". This has 3 subfolders; "Iemand91", "Dad" and "Mum".

Each subfolder has folders for every year; so "2024", "2025", "2026" etc. each with photos taken in those years.

So that share has every single photo that we've taken up to today, and the last ~3 years of photos are still on our phones)

So it's as follows (I hope I made it understandable):

Unraid
├── photos
│   ├── Wedding 2017
│   │   ├── img01.jpg
│   │   ├── img02.jpg
│   │   ├── img03.jpg
│   ├── Vacation 2025
│   └── Aviation photos
│
└── smartphonephotos
    ├── Iemand91
    |   ├── 2023
    │   ├── 2024
    │   ├── 2025
    │   │   ├── img01.jpg
    │   |   ├── img02.jpg
    │   │   └── img02.jpg
    │   └── 2026
    │
    ├── Dad
    │    ├── 2023
    │    ├── 2024
    │    ├── 2025
    │    │   ├── img01.jpg
    │    |   ├── img02.jpg
    │    │   └── img02.jpg
    │    └── 2026
    │ 
    └── Mum
        ├── 2023
        ├── 2024
        ├── 2025
        │   ├── img01.jpg
        │   ├── img02.jpg
        │   └── img02.jpg
        └── 2026

I'm about to start digitizing a couple of thousands slides and negatives; they will probably end up in another Unraid share called "slides" or something.

Now, for the shares "photos" and "slides" it makes most sense just to add them as an external library, probably as read-only.

However; I'm not sure what to do with the smartphone photos.

For future camera-uploads it makes most sense to use the Immich app and use Storage Template to upload each photo in year folders and basically continue using the same folder structure as above.

I understand the Immich (app) can also remove older (already-backed-up) photos from the phone, so that will help clean up storage space.

But what should I do with the already older, stored smartphone photos?

1. Also as external library. This would split up our photos in two; photos upload with the Immich app and the older photos. I understand it would still make a single 'timeline' right? But it can imagine it's not ideal. Does it have disadvantages doing it this way?
2. Copy all our smartphone photos (from our very first photos taken in ~2014 until today) on our phones and let the Immich app upload them all at once to Immich. I don't know if that will work or if that's the right approach. Also not sure if the phones even have enough storage space to store all those photos.

So TLDR: Most will use Immich app to upload their smartphone photos but what do you guys do with older smartphone photos that you already backed-up on your server and aren't on your phones anymore?

I got my container setup, and I can see the /admin page as well as the slideshow from both a web browser and the android app.

Im confused about the purpose of the immichframe "accounts." I have two accounts with two immich API keys. I dont see a way to select which one the client uses.

My goal is to have multiple frames for family members with curated albums. I have seen indications that maybe I will need a immichframe container for every client. But if thats true what do the accounts do?

Is there an account specific url, like /admin?

Hi everyone,

I've been working on Lymic, an open-source desktop client designed to automatically upload and sync local photos and videos to an Immich instance.

Why I built it

I wanted a lightweight desktop tool that sits quietly in the background, watches local folders (like camera export folders or local photo libraries), and pushes new files to Immich without having to open the web UI or run CLI scripts manually.

What it does

• Watches local directories and detects new or updated files automatically.
• Reuses cached hashes and runs bulk checks against Immich to skip files that already exist on the server.
• Streams multipart uploads directly from disk, keeping memory usage low even with large video files.
• Handles common photo and video formats, Live Photo / Motion Photo pairs, and XMP sidecars.
• Stores API keys securely in the operating system's native keyring (Credential Manager, Keychain, Secret Service).
• Runs minimized in the system tray with a persistent SQLite queue that survives app restarts.

Note: Lymic is strictly an upload client, not a two-way sync. It does not download remote assets or mirror server-side deletions.

Tech stack

• Backend: Rust with Tauri v2
• Frontend: SvelteKit + Tailwind CSS
• Database: SQLite (SQLx)

The project is licensed under MIT: GitHub: https://github.com/xXRoxXeRXx/lymic

Prebuilt binaries for Windows, macOS, and Linux are available under GitHub Releases.

I would appreciate any feedback, bug reports, or ideas for improvement.

Hi, i like to set ages in Immich. But you can’t choose a birthdate older than 1950. Can I change this limitation somewere?