DietPi-Software | Immich: Self-Hosted backup solution for photos and videos

[byalvaroft]

Formal software information

• Software title | Immich
• Short description | A self-hosted backup solution for photos and videos
• Official URL | [https://immich.app/]
• GitHub URL | [https://github.com/immich-app/immich/]
• (Official) install documentation | [https://documentation.immich.app/]
• Live Demo | [https://demo.immich.app/auth/login/]

Are there similar/alternative software titles available with DietPi-Software?

• Yes, there are some alternatives such as ownCloud, Nextcloud, and Syncthing.

What makes your requested software better than the above solutions, if available?

• Immich is designed specifically for photo and video backup, with features such as face recognition, object detection, geolocation, and timeline view. It also supports offline and untracked files management, which allows you to delete or move files from your device without affecting the backup. Immich has a user-friendly interface that resembles Google Photos, and it offers mobile apps for Android and iOS devices.

How can DietPi make the installation easier or compatible, than following the install instructions or do APT installation, if available?

• According to the official install documentation, there are several steps to install Immich on a Linux server, such as installing Docker, setting up environment variables, creating a PostgreSQL database, configuring Nginx, and running the Immich containers. DietPi could automate these steps, which would save end users a lot of time and hassle. DietPi could also provide an option to choose the storage location for the backup files, and integrate Immich with other DietPi services such as DietPi-Backup or DietPi-Drive_Manager.

Can you provide the installation steps that you would suggest DietPi-Software to do?

There is several installation methods: https://immich.app/docs/install/requirements, but they usually require some tinkering because or the arm64 v8, the easiest would be using this script:

curl -o- https://raw.githubusercontent.com/immich-app/immich/main/install.sh | bash

The script will perform the following actions:

Download docker-compose.yml, and the .env file from the main branch of the repository.
Populate the .env file with necessary information based on the current directory path.
Start the containers.

Are you willing to help maintaining the software installation, e.g. in case of needed setup changes due to updates etc.? This is not needed, but could speed up our decision to implement it, as man power is always a topic 😉.

• Sorry, I do not have the required skills to maintain the software installation. I hope someone else can help with this.

[t-bullock]

Can this be moved to discussions so it can be voted on? Would love to see immich get added to dietpi. Thank you!

[TommySharpNZ]

Yes please, this would be awesome to have a simple way to get Immich up and running!

[tundrablasen]

This would be awesome. Upvote.

Than I can finally replace my google photos subscription

[lukasMega]

➕1️⃣
I heard good reviews about performance of Immich on RPi5.

[GismoNo1]

Yeah, should run great on the RPi5. Upvote!

[supertevran]

Great!

[camplamao]

it would be nice to have a direct implementation of immich, thanks

[Androxilogin]

I'm also looking forward to this becoming a thing. Immich is all I'm missing from my little setup.

[Joulinar]

This app seems to be available on Docker only. Usually, we don't provide Docker container install options. All you need is Docker (available via dietpi-software) and running a single script curl -o- https://raw.githubusercontent.com/immich-app/immich/main/install.sh | bash

[Androxilogin]

I'll give it a try but I'll probably screw it all up.

[Joulinar]

should be quite easy

dietpi-software install 134 162
mkdir /mnt/dietpi_userdata/docker-data/immich
cd /mnt/dietpi_userdata/docker-data/immich
curl -o- https://raw.githubusercontent.com/immich-app/immich/main/install.sh | bash

after some minutes

[+] Running 6/6
 ✔ Network immich_default             Created
 ✔ Volume "immich_model-cache"        Created
 ✔ Container immich_machine_learning  Started
 ✔ Container immich_postgres          Started
 ✔ Container immich_redis             Started
 ✔ Container immich_server            Started
Successfully deployed Immich!

[felixwerner]

https://github.com/arter97/immich-native

haven't installed yet but looks like a good way around docker.

[Joulinar]

After a long time of waiting, we've done it. If you want to take a first look at Immich without Docker, you can switch to our dev branch and try installing Immich there.

A heads up to anyone with a small SBC, less than 2GB of memory and an SD card. Immich isn't a small application. It's a monster that needs to be compiled on the system first. We tried to keep it as lean as possible, but we hit some limits.

Installation can take between 5 and 10 minutes on modern SBCs, up to several hours on an RBi3B+.

For anyone who still wants to test it, feedback is super welcome. Is everything working? Is anything missing? Anything stand out?

For testing, this way, please:

G_DEV_BRANCH dev
dietpi-software install 215        #immich-core
dietpi-software install 216        #immich-machine-learning

Many thanks in advance, your DietPi development team.

[1021]

Wow, that is a lot of memory... My biggest hobby is photography though, and I have already been using Immich in a container on my desktop to help organize all my work for me, so I think being able to move it to a dedicated always-on sbc system is definitely worth it for my use case! I am also looking forward to being able to connect my phone through their mobile app to have all my pictures accessible everywhere as well.

This is giving me ideas now though, since you have pulled apart the core and ML components, I could see spreading the load between a cluster of two less capable 2GB systems, one with the web core and the other handling the ML tasks. Do you think you could offer the choice to install just the ML server on a system?

[Joulinar]

That's the main idea of having it split apart. But it was already quite late yesterday to do heavy testing. I just put both on a single RPI5. Will do more testing on weekend.

[Joulinar]

I just tested the distributed installation and it actually works quite well. If you have two SBCs, you should install ML on the more powerful one. ML simply requires more resources during operation. Here are the two diagrams for the RPI5 hosting ML and the OrangePi 5 hosting Immich Server.

RPI5 - ML

OPi5 - Immich

You can clearly see the difference in CPU and RAM usage.

[1021]

On my 8gb pi 5, the dev branch has been working well for me all weekend! The ML component installed with no problems on top of the existing core installation from last week and got to work cataloging images and faces with no fuss. The context sensitive search works very well too and returns results in a few seconds when the system is otherwise idle, even with the largest and most intensive ML search models selected. Total memory usage seems to have never exceeded 4gb. Excellent work, thank you again!

[Joulinar]

thx for letting us know

[nightflasher]

So my NAS system is an intel xeon E3-1265Lv2 and 8 GB RAM - will this be sufficient?

[MichaIng]

And I was playing with the idea to switch to 1&1 🤔. At least it is not a peering issue then.

As a potential debug step, does it work to install a smaller number of packages with npm?

tmp_dir=$(mktemp -d)
cd "$tmp_dir"
npm -d i nestjs-cls

[nightflasher]

Currently trying manually the docker version

[nightflasher]

the docker install went well and after some postgres password issues, the server is up and running. now i need to stop the ML. Is there an easy way?
EDIT: very easy - settings ML disable

IMPORTANT ::: I would suggest, when this is merged into upcoming dietpi versions, it needs to be with ML disabled.

[MichaIng]

I would suggest, when this is merged into upcoming dietpi versions, it needs to be with ML disabled.

Immich-ML is a dedicated software option, can be installed or skipped. If not installed, ML is disabled in Immich (or course, it cannot work) by default. Does not prevent users from re-enabling it in settings and entering a related hostname and port, e.g. if ML was installed separately on a different system, which is/will be possible with DietPi.

[MichaIng]

Btw, I see some connection issues as well with pnpm, but with the internal retries it goes through. Connections do not time out but I get 500 responses immediately, a buffer error in one case:

Progress: resolved 31, reused 0, downloaded 0, added 0
Progress: resolved 48, reused 0, downloaded 0, added 0
Progress: resolved 64, reused 0, downloaded 0, added 0
server                                   |  WARN  deprecated fluent-ffmpeg@2.1.3
Progress: resolved 105, reused 0, downloaded 0, added 0
Progress: resolved 111, reused 0, downloaded 0, added 0
Progress: resolved 151, reused 0, downloaded 0, added 0
Progress: resolved 185, reused 0, downloaded 0, added 0
Progress: resolved 211, reused 0, downloaded 0, added 0
Progress: resolved 229, reused 0, downloaded 0, added 0
Progress: resolved 231, reused 0, downloaded 0, added 0
Progress: resolved 258, reused 0, downloaded 0, added 0
Progress: resolved 285, reused 0, downloaded 0, added 0
Progress: resolved 326, reused 0, downloaded 0, added 0
Progress: resolved 378, reused 0, downloaded 0, added 0
Progress: resolved 447, reused 0, downloaded 0, added 0
Progress: resolved 457, reused 0, downloaded 0, added 0
 WARN  GET https://registry.npmjs.org/fast-safe-stringify error (ECONNRESET). Will retry in 10 seconds. 2 retries left.
Progress: resolved 485, reused 0, downloaded 0, added 0
Progress: resolved 531, reused 0, downloaded 0, added 0
Progress: resolved 633, reused 0, downloaded 0, added 0
Progress: resolved 699, reused 0, downloaded 0, added 0
Progress: resolved 730, reused 0, downloaded 0, added 0
Progress: resolved 786, reused 0, downloaded 0, added 0
Progress: resolved 827, reused 0, downloaded 0, added 0
Progress: resolved 829, reused 0, downloaded 0, added 0
Progress: resolved 846, reused 0, downloaded 0, added 0
Progress: resolved 888, reused 0, downloaded 0, added 0
 WARN  Request took 10482ms: https://registry.npmjs.org/fast-safe-stringify
 WARN  GET https://registry.npmjs.org/@smithy%2Fmiddleware-stack error (500). Will retry in 10 seconds. 2 retries left.
Progress: resolved 999, reused 0, downloaded 0, added 0
Progress: resolved 1045, reused 0, downloaded 0, added 0
Progress: resolved 1116, reused 0, downloaded 0, added 0
Progress: resolved 1174, reused 0, downloaded 0, added 0
Progress: resolved 1253, reused 0, downloaded 0, added 0
Progress: resolved 1287, reused 0, downloaded 0, added 0
Progress: resolved 1362, reused 0, downloaded 0, added 0
Progress: resolved 1434, reused 0, downloaded 0, added 0
Progress: resolved 1521, reused 0, downloaded 0, added 0
Progress: resolved 1573, reused 0, downloaded 0, added 0
 WARN  Request took 10235ms: https://registry.npmjs.org/@smithy%2Fmiddleware-stack
Progress: resolved 1631, reused 0, downloaded 0, added 0
Progress: resolved 1696, reused 0, downloaded 0, added 0
Progress: resolved 1813, reused 0, downloaded 0, added 0
Progress: resolved 1946, reused 0, downloaded 0, added 0
Progress: resolved 2062, reused 0, downloaded 0, added 0
 WARN  GET https://registry.npmjs.org/@aws-sdk%2Fcredential-provider-ini error (Z_BUF_ERROR). Will retry in 10 seconds. 2 retries left.
Progress: resolved 2118, reused 0, downloaded 0, added 0
Progress: resolved 2218, reused 0, downloaded 0, added 0
Progress: resolved 2289, reused 0, downloaded 0, added 0
Progress: resolved 2421, reused 0, downloaded 0, added 0
Progress: resolved 2509, reused 0, downloaded 0, added 0
Progress: resolved 2603, reused 0, downloaded 0, added 0
Progress: resolved 2667, reused 0, downloaded 0, added 0
Progress: resolved 2668, reused 0, downloaded 0, added 0
Progress: resolved 2689, reused 0, downloaded 0, added 0
 WARN  16 deprecated subdependencies found: abab@2.0.6, are-we-there-yet@2.0.0, domexception@4.0.0, gauge@3.0.2, glob@10.5.0, glob@11.1.0, glob@7.2.3, inflight@1.0.6, mkdirp@0.3.0, npmlog@5.0.1, rimraf@3.0.2, tar@6.2.1, tar@7.5.2, text-encoding@0.6.4, whatwg-encoding@2.0.0, whatwg-encoding@3.1.1
Progress: resolved 2708, reused 0, downloaded 0, added 0
Progress: resolved 2708, reused 0, downloaded 0, added 0, done
.                                        |    +1554 ++++++++++++++++++++++++++++
 WARN  GET https://registry.npmjs.org/get-intrinsic/-/get-intrinsic-1.3.0.tgz error (ERR_PNPM_FETCH_500). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/bl/-/bl-4.1.0.tgz error (ERR_PNPM_FETCH_500). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@eslint/js/-/js-9.39.2.tgz error (ECONNRESET). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@xtuc/long/-/long-4.2.2.tgz error (ECONNRESET). Will retry in 10 seconds. 2 retries left.
.../bcrypt@6.0.0/node_modules/bcrypt install$ node-gyp-build
.../sharp@0.34.5/node_modules/sharp install$ node install/check.js || npm run build
.../bcrypt@6.0.0/node_modules/bcrypt install: Done
.../sharp@0.34.5/node_modules/sharp install: Done

In the GitHub CI runs I do not see any such warnings.

Btw, if you use the officially suggested Docker Compose setup, and disable ML, you might want to remove the related ML container as well: the immich-machine-learning one, can be removed from the docker-compose.yaml to prevent it from being installed in the first place.

[MichaIng]

I just tested the Immich Docker container setup, to check whether they do something better regarding RAM usage. But seems to be pretty much the same:

• A bit above 2 GiB memory usage on fresh install in idle.
• When starting to use the web UI and uploading images, the Postgres workers kick in and push it above 2.5 GiB.
• Once images arrive, the ML server starts working, raising its memory usage to 1 GiB (with 177 images overall), where it remains. EDIT: And exif processes appear to produce previews/thumbnails and such for the new images.
• Doing a "context" search, raises it to 1.2 GiB, where it remains. Idle now above 2.75 GiB.
• Peak during upload processing of the 177 images was above 3.5 GiB.
• The Docker engine with proxies etc adds roughly 200 MiB, which we safe.
• But otherwise it looks very similar, same processes, same PostgreSQL configuration (number of workers), same memory usage each. So Immich is huge (for an image gallery), Docker yes or no plays only a marginal role for overall resource usage, but the possibility to run core and ML on dedicated machines, or skip the ML, is quite a nice benefit of our setup.

Oh I just see that after some minutes, ML memory usage drops back to ~400 MiB with all its processes. Looks like there is some cleanup scheduled. But every search adds ~300 MiB again.

So yeah, I think we can say:

• Minimum 2 GiB physical RAM for Immich core, which is very tight already, means swapping during operation, maybe even in idle when it is used with large galleries.
• 4 GiB physical RAM when adding ML on the same host. Idle will have some more buffer, but tight during operation. Swapping will happen, though possible only for more persistent data. 3 GiB will cause more issues than 2 GiB without ML.

Possible enhancements to tight memory setups:

• The number of CPU cores have an effect on the number Postgres workers, hence memory usage (~150 MiB per worker), so it can make sense to limit these, or limit the max memory each worker can use, to prevent swapping.
• Also, it can make sense to play with zram swapping, e.g.:

  /boot/dietpi/func/dietpi-set_swapfile 2048 zram
  

  That way, up to 2 GiB memory data is compressed, but remains in RAM. This adds some CPU processing for compression/decompression when swapping is done, but the impact on performance is usually some magnitude of order(s) smaller than swapping to disk. Default algorithm should be zstd with most kernels.

[nightflasher]

How do i limit the cpu cores?

[Joulinar]

I guess you are still running the Docker version? if yes, this has nothing to do with DietPi. You would need to adjust your container configuration. Basically you could add parameters like cpus or cpuset to reduce CPU usage or to pin the process to specific cores.

[MichaIng]

Crazy how a little less RAM can lengthen the build so massively: 4 GiB RAM => less than 5 minutes overall, 2 GiB RAM => 1:20 hours, on the very same VM. And host has a fast NVMe SSD for swapping.

@Joulinar found the immich-config.json to define the max number of concurrent AI processing jobs, to be able to reduce peak RAM usage when uploading many images at once. Might make sense to limit each of them to max the number of CPU cores, and more depending on the amount of physical RAM. If any parallel job leads to swapping, it effectively slows down the whole processing significantly, instead of speeding it up. Below 2/4 physical RAM without/with Immich core, e.g., limiting all jobs to max 1 could make sense.

[Joulinar]

@MichaIng I did some testing the last days and was playing with the number of jobs. Can show you some interesting graphs tomorrow.

[MichaIng]

Great, that will be interesting!

[miguelpruivo]

That's a great addition. I've been using it with docker but solely running docker for this service alone as all my other services are managed by dietpi-software. However I've been limiting the number of cores to 2 for the ML container.

Do you expect any improvement in performance over the docker version that can make it worth it to move it to the dietpi-software managed or should it be more or less the same?

Keep up the great work!

[miguelpruivo]

Congratulations then, if I interpret those words correctly? 🙂

You did! Thank you. Having a newborn gave me one more reason to use local photo storage and get rid of cloud so I can keep my family stuff “mine”. Specially these days with all of the AI fuss using everyone’s data to train.

[Joulinar]

Having a newborn

Congratulations, Enjoy the moment. It may be challenging, but it’s truly beautiful.

[Joulinar]

coming back to some performance test. I haven’t set any limits on CPU usage or memory consumption. The only adjustment I made was to limit the number of concurrent jobs per category to 1 in the UI. Runtime: 2 hours 8 minutes.

Compared to MACHINE_LEARNING_REQUEST_THREADS=1, memory usage is similar and never goes into SWAP. However, the CPU is used more here, which is also reflected in the shorter runtime.

My personal conclusion is that I would prefer MACHINE_LEARNING_REQUEST_THREADS=1 rather than limiting the number of concurrent jobs. The runtime for indexing is usually determined by facial recognition and OCR. And I wouldn’t mind if those came through a little later. What’s important is the generation of the thumbnails. In my personal opinion, MACHINE_LEARNING_REQUEST_THREADS=1 strikes a good balance. There is an increased CPU load at the start, but this drops off relatively quickly once the images have been initially added to the gallery. Special features such as face recognition and OCR do take longer, but the system doesn’t go into SWAP mode, and the longer processing time keeps the CPU load and temperature within reasonable limits. But that’s just my opinion, and I’m sure everyone here has different needs or different hardware.

[miguelpruivo]

Where are you setting the MACHINE_LEARNING_REQUEST_THREADS as a persistent value?

[Joulinar]

to be done in /mnt/dietpi_userdata/immich-ml/immich-ml.env. It will be persistent an get active on next systemd service start

[miguelpruivo]

Providing feedback (and not sure if this is related with this version or general) but any HEIC file doesn't seem to work at all (in any client, app or web).

Apparently it is supported and I believe it was working with the docker version, so it's odd.

[miguelpruivo]

@MichaIng @Joulinar I think this is something that should be looked up before promoting this to the main branch. Basically all HEIC images don't work on this release but I can't really pin down to what may be causing it, the libheif1 is installed properly.

This is the output of the vips --vips-config:

enable debug: false
enable deprecated: true
enable modules: true
enable cplusplus: true
enable RAD load/save: true
enable Analyze7 load: true
enable PPM load/save: true
enable GIF load: true
FFTs with fftw3: true
SIMD support with libhwy: true
ICC profile support with lcms2: true
deflate compression with zlib: true
text rendering with pangocairo: true
font file support with fontconfig: true
EXIF metadata support with libexif: true
JPEG load/save with libjpeg: true
JXL load/save with libjxl: true (dynamic module: true)
JPEG2000 load/save with libopenjp2: true
PNG load/save with spng: true
image quantisation with imagequant: true
TIFF load/save with libtiff-4: true
image pyramid save with libarchive: true
HEIC/AVIF load/save with libheif: true (dynamic module: true)
WebP load/save with libwebp: true
PDF load with poppler-glib: true (dynamic module: true)
SVG load with librsvg-2.0: true
EXR load with OpenEXR: true
WSI load with openslide: true (dynamic module: true)
Matlab load with matio: true
NIfTI load/save with libnifti: false
FITS load/save with cfitsio: true
GIF save with cgif: true
Magick load/save with MagickCore: true (dynamic module: true)

[miguelpruivo]

More logs:

ar 19 14:45:45 DietPi Immich[52344]: heif: Error while loading plugin: Support for this compression format has not been built in (11.6003)
Mar 19 14:45:45 DietPi Immich[52344]: Error: /mnt/dietpi_userdata/immich/upload/upload/df4374f8-7b78-4eb1-9897-dc8efd81216e/ea/2e/ea2ea8be-f2ab-4ab2-86a1-3a89b5ec67b2.HEIC: bad seek to 2249969
Mar 19 14:45:45 DietPi Immich[52344]: /mnt/dietpi_userdata/immich/upload/upload/df4374f8-7b78-4eb1-9897-dc8efd81216e/ea/2e/ea2ea8be-f2ab-4ab2-86a1-3a89b5ec67b2.HEIC: bad seek to 2249952
Mar 19 14:45:45 DietPi Immich[52344]: /mnt/dietpi_userdata/immich/upload/upload/df4374f8-7b78-4eb1-9897-dc8efd81216e/ea/2e/ea2ea8be-f2ab-4ab2-86a1-3a89b5ec67b2.HEIC: bad seek to 2249943
Mar 19 14:45:45 DietPi Immich[52344]: /mnt/dietpi_userdata/immich/upload/upload/df4374f8-7b78-4eb1-9897-dc8efd81216e/ea/2e/ea2ea8be-f2ab-4ab2-86a1-3a89b5ec67b2.HEIC: bad seek to 2249939
Mar 19 14:45:45 DietPi Immich[52344]: /mnt/dietpi_userdata/immich/upload/upload/df4374f8-7b78-4eb1-9897-dc8efd81216e/ea/2e/ea2ea8be-f2ab-4ab2-86a1-3a89b5ec67b2.HEIC: bad seek to 2249938
Mar 19 14:45:45 DietPi Immich[52344]: heif: Error while loading plugin: Support for this compression format has not been built in (11.6003)
Mar 19 14:45:45 DietPi Immich[52344]:     at Sharp.toBuffer (/opt/immich/node_modules/.pnpm/sharp@0.34.5/node_modules/sharp/lib/output.js:163:17)
Mar 19 14:45:45 DietPi Immich[52344]:     at MediaRepository.decodeImage (/opt/immich/dist/repositories/media.repository.js:120:31)
Mar 19 14:45:45 DietPi Immich[52344]:     at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
Mar 19 14:45:45 DietPi Immich[52344]:     at async MediaService.decodeImage (/opt/immich/dist/services/media.service.js:186:32)
Mar 19 14:45:45 DietPi Immich[52344]:     at async MediaService.extractOriginalImage (/opt/immich/dist/services/media.service.js:196:44)
Mar 19 14:45:45 DietPi Immich[52344]:     at async MediaService.generateImageThumbnails (/opt/immich/dist/services/media.service.js:220:32)
Mar 19 14:45:45 DietPi Immich[52344]:     at async MediaService.handleGenerateThumbnails (/opt/immich/dist/services/media.service.js:153:25)
Mar 19 14:45:45 DietPi Immich[52344]:     at async JobService.onJobRun (/opt/immich/dist/services/job.service.js:51:30)
Mar 19 14:45:45 DietPi Immich[52344]:     at async EventRepository.onEvent (/opt/immich/dist/repositories/event.repository.js:91:13)
Mar 19 14:45:45 DietPi Immich[52344]:     at async /opt/immich/node_modules/.pnpm/bullmq@5.66.5/node_modules/bullmq/dist/cjs/classes/worker.js:565:32

[MichaIng]

That is helpful:

heif: Error while loading plugin: Support for this compression format has not been built in

So I am sure we need to install libheif-dev before building Immich.

[Joulinar]

Problem is the npm module sharp that is used by Immich. Not sure if we can rebuild the sharp module with HEIC/HEVC enabled. Something to look into.

[Joulinar]

ok got HEIC/HEVC pictures working, but it was needed to compile libvips + libheif locally with HEIF support enabled, before building Immich 😢

[miguelpruivo]

Another issue (maybe I am missing something). I updated the env to store the images on my mnt/data/images directory with the correct permissions and user owner/group (immich), but the service now always fails to start with:

Mar 18 02:41:47 DietPi Immich[8718]:     at async /opt/immich/dist/services/storage.service.js:56:21
Mar 18 02:41:47 DietPi Immich[8718]:     at async /opt/immich/dist/repositories/database.repository.js:368:27
Mar 18 02:41:47 DietPi Immich[8718]:     at async /opt/immich/node_modules/.pnpm/kysely@0.28.2/node_modules/kysely/dist/cjs/kysely.js:535:20
Mar 18 02:41:47 DietPi Immich[8718]:     at async DefaultConnectionProvider.provideConnection (/opt/immich/node_modules/.pnpm/kysely@0.28.2/node_modules/kysely/dist/cjs/driver/default-connection-provider.js:12:20)
Mar 18 02:41:47 DietPi Immich[8718]:     at async /opt/immich/dist/repositories/database.repository.js:365:13

[Joulinar]

To be able to assist you would need to share everything you have done and how your configuration files looks like

[miguelpruivo]

@Joulinar assume an installation from scratch at this point of Immich.

The goal is to set the media storage on /mnt/data/images while keeping the thumbs in the /mnt/dietpi_userdata.

[MichaIng]

Did you set ReadWritePaths=-/mnt in the systemd unit already?

[Joulinar]

systemctl stop immich.service
mv /mnt/dietpi_userdata/immich/upload/upload /mnt/data/images/
mv /mnt/dietpi_userdata/immich/upload/encoded-video /mnt/data/images/
ln -s /mnt/data/images/upload /mnt/dietpi_userdata/immich/upload/upload
ln -s /mnt/data/images/encoded-video /mnt/dietpi_userdata/immich/upload/encoded-video
systemctl start immich.service

That's all you need to do to move the picture upload and encoded videos.

[miguelpruivo]

Got it working now. Thanks!

[miguelpruivo]

Adding one more question to this thread.

Immich 2.6.0 was released today, I ran dietpi-update in order to update it, but turns out it didn't. How will dietpi keep this kind of software updated?

[MichaIng]

dietpi-update never updates dietpi-software options beyond APT packages. In this case, a reinstall is needed for the upgrade:

dietpi-software reinstall 215

Will be also in the docs.

[miguelpruivo]

Just to confirm: does this mean that everytime there's a new version, we will need to manually run this?

[Joulinar]

Yes, this will be documented in our online docs as well

[MichaIng]

@miguelpruivo
To combine both your last comments, can you test this:

sudo apt install libheif-dev
dietpi-software reinstall 215

This should update to v2.6.0 with HEIF/HEIC support included.

[miguelpruivo]

I’ve been told by the Immich community to check the source of the LXC script here.

[MichaIng]

They compile libheif with -DWITH_X265=OFF, hence this does not support HEIC either. Decoding yes, but not thumbnail generation e.g. Best source is the Dockerfile of the Immich base container. But we know that already, and same build from scratch on a clean system works.

[Joulinar]

If you really want to do this, I have a script that can enable HEIC support. It’s not the most elegant solution, but it seems to work most of the time. Basically, it compiles libheif and libvips from source with the appropriate settings for HEIF/HEVC. Before running it, you should definitely back up your system, as we cannot guarantee that it will work. Immich must then be reinstalled so that Sharp can integrate the new libraries correctly.

Last chance to reconsider. Click to expand!

#!/bin/bash
set -e

echo "=== Installing build dependencies ==="
sudo apt update
sudo apt install -y build-essential meson ninja-build cmake git pkg-config \
libjpeg-dev libpng-dev libwebp-dev libtiff-dev libexpat1-dev libffi-dev \
libglib2.0-dev libxml2-dev libexif-dev liborc-dev libgsf-1-dev \
libimagequant-dev libaom-dev libdav1d-dev libde265-dev libx265-dev libde265-0

echo "=== Building libheif with HEVC support ==="
cd /tmp
git clone https://github.com/strukturag/libheif.git
cd libheif
mkdir build && cd build
cmake -DWITH_X265=ON -DWITH_DE265=ON ..
make -j$(nproc)
sudo make install

echo "=== Building libvips with HEIF support ==="
cd /tmp
git clone https://github.com/libvips/libvips.git
cd libvips
meson setup build --prefix=/usr/local --libdir=lib \
-Dheif=enabled -Djpeg=enabled -Dpng=enabled -Dtiff=enabled
ninja -C build
sudo ninja -C build install

echo "=== Reloading shared library cache ==="
sudo ldconfig

echo "=== Cleanup build ==="
cd /tmp
sudo rm -Rf libheif libvips

sudo apt update
sudo apt autoremove -y libheif* libde265-dev libx265-dev

echo "=== DONE: Immich can use system libvips/libheif with full HEVC support now ==="

[miguelpruivo]

Thank you.

I think for now I will stick with the docker approach until this gets sorted, just to play on the safe side.

Immich supports backups so later on I can always switch back.

Nevertheless really thank you for all your effort on this.

[MichaIng]

Thanks for testing and all the feedback! We will let you know once we have own libvips builds that support HEIC.

[jcw]

Just a quick thumbs-up: I installed immich + immich-ml on RasPi5 w/ 8G RAM. Absolute no-brainer.

Works well! A splendid step up from the PhotoPrism I was running on my (underpowered) NAS. Our photo collection still lives there, it's connected via SMB as an external library.

A small quirk, not investigated yet, is that after a reboot I need to re-activate the immich-ml service, it shows up as "failed".

[Joulinar]

A small quirk, not investigated yet, is that after a reboot I need to re-activate the immich-ml service, it shows up as "failed".

pls create an issue and provide the service whole log after reboot