The upstream Immich project has changed the configuration format for metrics in the v1.119.0 release. You will be affected if you have enabled metrics-enabled and configured metrics-api-enabled, metrics-host-enabled, metrics-io-enabled or metrics-job-enabled to limit collected telemetries.
Check out the metrics documentation for more information.
Upstream Immich has this message attached to the release page for Immich 1.113. If you use OAuth with the mobile application you need to update your OAuth provider like below.
For OAuth users, please replace
app.immich:/withapp.immich:///oauth-callbackfor the Redirect URI in your OAuth provider settings
For more information see the upstream GitHub issue.
The build time has been abysmal, over 40 minutes. Everything from Postgres to Python was built in a single 658 lines snapcraft.yaml file. It has just sort of evolved over time.
This has been one of the classic: I do not have time to fix this, so I have lost time waiting for builds. I have tried to fix this twice, first with cache, and later on with snaps as a dependency. The first one introduced complexity, and the second one did not work that well, I had to fight the tooling.
I known that package the dependencies in deb packages was probably the smart thing to do, but I did not have the energy to figure out how to set it up, so I have stalled. But it's now done, I have created 14 different packages of cgif, ffmpeg, haproxy, imagemagick, lego ,libde265, libheif, libraw, libvips, mimalloc, postgres, python, redis and x265. You can read more about the repository here.
For the curious, I build the packages in clean OCI images (with Podman). The deb packages are created with fpm and I use Aptly to manage the repository. I have also created a few bash scripts to "build", "add to repo" and "publish" to make life easier for future me.
The observant have seen that I'm down from 40 minutes to 17. I'm actually expected it to be lower but Immich takes a long time to build, and the resulting snap takes several minutes to compress. It's still over twice as fast. I also added a build cache, so if I only tweak the tests, it can reuse the cached snap package. That makes tweaking and troubleshooting much faster.
I had a test failure that only occurred on GitHub, it required a lot of rebuilds. I needed a distraction, and a distraction that also reduce the build time sounded like a good idea. This was also a good time to delay a release a little, this was the purchase a license release and I preferred to wait a little before it resolved it self. There have also not been any breaking changes.
We have a new logo. Immich changed logo earlier this year and I have always felt that my old logo was rushed and more of a placeholder. The old logo was the outer ring of Immich old logo with a box in the middle reflecting on the fact that Immich Distribution is a package of Immich.
| New | Old |
|---|---|
 |
 |
I moved "Immich" inside the box in the new logo, it's better reflects what's going on. I also choose to not reuse parts of the new logo due the fact that the new logo is probably trademarked by FUTO. The colored leaves have the same basic shape as the leaves in the new Immich logo. I kept the red theme from the old logo. I feel that this also better reflects that Immich Distribution also contains more things, like databases, extra features and so on.
I noticed from the logs of the ACME client (lego) that there was a port conflict preventing new certificates from being issued. I uses port 8081 since last year. About two months ago Immich started to use the same port to expose metrics.
To resolve the port conflict preventing new certificates from being issued, I decided to change the port used by the ACME client (lego). While the ACME thing is something internal that users do not need to worry about, the Immich metrics ports could be utilized by my users. Therefore, I made the decision to switch the Lego port instead of the Immich port.
Initially I just changed the Lego port to 8181 and explicitly configured Immich to use 8081. The problem with new ports and an automatically updating application is that I have no idea if a user have additional software already installed utilizing 8181. I thought about picking a higher port, reducing the risk of a port conflict to almost 0 but I choose a more programmatic approach.
Last year I introduced two new configuration options that allowed the user to change the HTTP (default 80) and HTTPS (default 443) ports. I already had the code for most of the logic, so I wrote a simple function to detect a free port in the 34000-36000 port range and used that port by default.
On my system I got port 34000 and most likely, so did you. to change the port use this command:
I plan to utilize this new functionality to assign internal ports for Immich (3001-3003), as well as the database ports 5432 (postgres) and 6379 (redis). My goal is to make the installation of Immich Distributions easier on systems that have other services running.
To increase security, with the release of Immich Distribution v1.102 and forward, the backend services will no longer listen on all interfaces. They will only bind to 127.0.0.1:3001, 127.0.0.1:3002 and 127.0.0.1:3003 respectively.
In a less tech-y way. You must access Immich Distribution via HAProxy on port 80 (http) or 443 (https). This has always been the supported and expected way to use Immich Distribution so I do not consider this a breaking change. If anyone has the need to access it directly, open an issue and we can discuss a solution for you.
Yesterday was the one year mark of Immich Distribution. It's has been a fun and interesting year with a few ups and downs. Let's reflect on the past year and try to guess about the future.
commit 72d549a5c0344f89a4173623a3f7eaedab6c54ef
Author: Stefan Berggren
Date: Sat Mar 11 12:20:32 2023 +0100
init
I have made zero effort to announce the project over the year (except publishing it in the Snap Store). A slow grow was to my advantage, a year ago I had no idea how hard this would be and I like to stay a little quiet while I test the waters.
The upstream Immich projects developers warned me that it may be hard to automatically upgrade a project like Immich in it's current state. I disagreed and thought that this should be doable. They where happy that I was clear that this was an unofficial package. That was important to me, I had no wish to cause any disturbance to them.
I'm happy to report that I have been able to automatically upgrade every single release except one last summer. A few users had to run a single command manually. It's possible that I was the only one affected because it only affected people with older installations.
I think that Immich popularity has been to my advantage, upstream have been forced to be a little more careful when releaseing breaking changes. Most breaking changes has been changes to the configuration files or database versions. Everyting is packaged inside the snap package in Immich Distribution so that has not been a problem for me.
I have had a few occurrences when I considered giving up, especially when I had to troubleshoot buggy or weird libraries for weeks. Some have been a pain and taken a lot of energy from me. This is someting I do as part of my free time, and when the time and motivation has lacked, progress has been slow.
It has been fun to see the users slowly grow. My snap is tiny compared to the official release, and even small compared to the other community packages. But with zero marketing that is expected! That is something I think will change during 2024, because I intend to spread the word a little!
I also published a nice graph with the 89 Immich releases over the last year! 🤯
This release bumps the version of pgvecto.rs to 0.2.0. The index format has changed and a few database operations are needed. Immich runs these operations as part of it's normal migrations. The problem is that Postgres needs to be restarted after. So the official instructions are just that. "Upgrade, wait, restart".
I considered to manually run these database migrations as part of the update hook, alternatively as part of the database startup script. That would have been a clean solution, but I'm a little worried that I would have missed something extra that Immich needes, so I followed the official instructions.
The database restart needs to occur after immich has started. I considered writing some form of logic to detect the appropriate time, but to keep things simple, I just wait five minutes. A simple solution, good enough!
I created a simple "migration" service that I use to trigger this logic. It felt better to write something more generic instead of a one off script that I needed to keep around for months (a few users are slow to upgrade).
Zero care automatic updates as usual. If you actively use the system the first five minutes you may notice that search is broken. It should fix it self after five minutes.
If search is still broken, please open an issue and report the output of:
I noticed that I was unable to process a CR2-file (I think other RAW image formats may have been affected as well). The problem was that libvips fails to difference between TIFF-images and image formats based on top of TIFF like Canons CR2 RAW image format. ImageMagic handles this properly so the fix was to remove TIFF-support from libvips. Libvips will send all unknown formates down to ImageMagic.
ImageMagic is slower compared to libvips so this will slow down TIFF processing a little, but it will fix several RAW image formats. This fix reflects what upstream has done already and I consider it a bug that I missed this when I build my own version of libvips.
I have upgraded mkdocs-material to the latest version and enabled the blog. This was earlier a payed feature. I have migrated all old news articles over.