Arch Linux User Repository

Upgrading to postgresql-17 is awkward because of pgvecto.rs if you have been using 0.2.0 as provided by AUR package pgvecto.rs-immich. If you have been using 0.3.0 as provided by AUR package pgvecto.rs-immich-bin then these extra steps are likely not required and I suggest the wiki instructions for upgrades for major version increments of postgresql are followed.

If you would like to stick at postgresql-16 please add the following to pacman.conf:

IgnorePkgs = postgresql postgresql-libs

Following the manual dump and reload in the wiki does appear to work, with a few extra steps to consider the pgvecto.rs upgrade.

Starting point is postgresql-old-upgrade installed with pgvector.rs-0.2.0. Symlink the installation outputs of pgvecto.rs into the directories used by the parallel installation of postgresql-old-upgrade.

ln -s /usr/share/postgresql/extension/vectors.control /opt/pgsql-16/share/extension/vectors.control
ln -s /usr/share/postgresql/extension/vectors--0.2.0.sql /opt/pgsql-16/share/extension/vectors--0.2.0.sql
ln -s /usr/lib/postgresql/vectors.so /opt/pgsql-16/lib/vectors.so

Then perform the database start (/opt/psql-16/bin/pg_ctl .. start), "dump" (pg_dumpall...) and database stop (/opt/psql-16/bin/pg_ctl .. start) steps in the wiki.

Upgrade to postgresql-17 and pgvecto.rs-0.3.0 (provided by pgvector.rs-immich-bin). Clear out /var/lib/postgresql/data then initialise the database (initdb...) as per the wiki.

Start the service using systemctl start postgresql and install the pgvecto.rs using the following command:

psql -c 'ALTER SYSTEM SET shared_preload_libraries = "vectors.so"'

Finally restart the postgresql service and perform the reload (psql...) steps in the wiki.

EDITED: Various clarifications

From v1.111.0, this package does not build with nodejs < v20.

Immich provides release files, I wonder if there is a prebuilt frontend there? Just to avoid building that mess:

--- Last few GCs --->

[25393:0x598a99c4c000]    49922 ms: Scavenge (interleaved) 472.4 (479.9) -> 471.1 (484.4) MB, pooled: 0 MB, 16.16 / 0.00 ms  (average mu = 0.208, current mu = 0.111) allocation failure; 
[25393:0x598a99c4c000]    50428 ms: Mark-Compact (reduce) 475.3 (484.4) -> 473.1 (479.6) MB, pooled: 0 MB, 110.03 / 0.00 ms  (+ 322.6 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 506 ms) (average mu = 0.244, c

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0x598a815eb9db node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
 2: 0x598a81ab9f64 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 3: 0x598a81aba339 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 4: 0x598a81d0557c  [node]
 5: 0x598a81d055a4  [node]
 6: 0x598a81d1c8fe  [node]
 7: 0x598a81d1fb04  [node]
 8: 0x598a82772a67  [node]
/home/dmig/.cache/yay/immich/PKGBUILD: line 70: 25382 Aborted                 (core dumped) npm run build
==> ERROR: A failure occurred in build().
    Aborting...

Thank you for maintaining. According to https://v1.120.2.archive.immich.app/docs/install/environment-variables#database , both pgvector and pgvecro.rs should be supported. Additionally, can you separate immich-machine-learning into a separate sub package, so that it can be installed on different machines instead of being strongly dependent on the immich-server ontology using optdepends. Finally, I took over the maintenance of python-ftfy and python-insightface. Now, all the Python packages required for immich-machine-learning can be obtained from the official repository and AUR, and can no longer be installed in a virtual environment. I have tested it myself and it runs like this. All the required Python packages for immichh machine learning are as follows:

gunicorn
python-aiocache
python-fastapi
python-ftfy
python-huggingface-hub
python-insightface
python-onnxruntime
python-orjson
python-python-multipart
python-rich
python-tokenizers
uvicorn

There are several dependency packages for immich-machine-learning that have already been dependent on the packages mentioned above:

python-opencv
python-pillow
python-pydantic

v1.102.2-2 fixes software transcode and thumbnail generation for videos due to upstream PR. After @mertalev kindly made us aware of this, ffmpeg dependency was switched for jellyfin-ffmpeg - however since the latter depends on the former, both are installed and immich carried on using the standard version.

v1.102.2-2 forces usage of jellyfin-ffmpeg by using BindReadOnlyPaths= in the systemd service file.

If you have an failed thumbnails/transcoded videos, after upgrading, run the transcode video and generate thumbnail admin jobs for missing items.

@zynex I've been unable to reproduce this with immich v1.120.2 and openexr v3.3.2-1. Clean chroot build and installation hasn't thrown up any problems. Can you please check with this combination?

I've tried recompiling and it still has the libOpenEXR-3_2.so.31 error.

@zynex that sounds like recompiling Immich could fix it.

Just a note, the latest openexr v3.3.1 will break Immich. I had to downgrade to v3.2.4 to get it up and running again. It will fail with error ERR_DLOPEN_FAILED: libOpenEXR-3_2.so.31: cannot open shared object file: No such file or directory.

Thanks mertalev. Dependency now updated in 1.119.1-1.

Hi! Immich maintainer here. I see that this package uses the standard FFmpeg build as a dependency. We highly suggest using jellyfin-ffmpeg (https://archlinux.org/packages/extra/x86_64/jellyfin-ffmpeg/) instead for a number of reasons:

• We assume FFmpeg has been built with support for certain features and libraries
• We assume the custom filters and encoders added by the Jellyfin team are available
• This FFmpeg build has a number of important fixes and improvements not present in the standard build
• This is the build we use to test our transcoding pipeline

Importantly, release v1.120.0 will use a different SW tone-mapping filter not in the standard build. This means that unless jellyfin-ffmpeg is used, HDR videos will fail to transcode and thumbnails for these videos will fail to be generated in the default configuration.

Any one else experience issues with RAW-files (NEF in my case) using a low res thumbnail when generating previews? Have a thread on their GitHub regarding this (https://github.com/immich-app/immich/issues/13576), but the issue doesn't seem to affect the dev using Docker installation.

[EDIT] It seems to be an issue within the libvips, converting NEF files produces a small 160x120 image :P

Confirmed the error. Needed to rebuild libvips with -Dtiff=disabled option (the Docker installation from the devs is compiled with this option), after this the conversion works. I added a package to resolve this for those who needs it here https://aur.archlinux.org/packages/libvips-notiff.