Arch Linux User Repository

You may notice pacman refuse to upgrade this package, saying warning: cannot resolve "vectorchord", a dependency of "immich-server".

This is due to required manual intervention within the immich server database.

Newer versions of immich server have deprecated pgvecto.rs in favor of vectorchord.

Before updating from 1.133.1 or older, please follow steps 1 and 2 of the manual migration steps (should be the second dropdown) at https://immich.app/docs/administration/postgres-standalone/#migrating-to-vectorchord and uninstall pgvecto.rs.

Remember to remove references to "vectors.so" (which is shipped by pgvecto.rs) in shared_preload_libraries before pgvecto.rs in uninstalled. (For vectorchord to work, you'll need to add "vchord.so" to shared_preload_libraries after the upgrade as well.)

After that, you may upgrade this package. Please remember to follow steps 4 and 5 of the manual migration steps after the upgrade is finished to prevent data loss.

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

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.

Version 1.118.0 is released. Note that some changes are needed, microserver.service must be removed also the node argument is removed; ExecStart=node dist/main (remove immich argument). Also port is changed to 2283.