Immich broken after update to 3.0.1

[james]

Hello @sansguidon
First thing you should do in these cases is the following.

• create a backup of the broken state
• restore the backup from before the update (working state)
• create a clone of the app from the broken app backup
• with the broken cloned app you can tinker and try to apply the fixes mentioned in the log

This way you 'production' immich stays online, and you can investigate the issue without potentially causing further harm.

We did not encounter this issue in our CI.
Can you check if maybe your postgresql was/is running out of memory causing this issue while updating the immich app?

[nebulon]

haven't seen this in my production instance, especially strange about the db schema issues, since immich performs db migration on startup, so all I can think of is, that some run may have crashed mid way, so maybe try to rollback and try again for that.

But before this, do you have made any tweaks to the configuration, since there is another issue:

Jul 05 21:56:31 Error: Invalid system config:
Jul 05 21:56:31 - [ffmpeg.acceptedAudioCodecs.2] Invalid option: expected one of "mp3"|"aac"|"opus"|"pcm_s16le"

which could be the reason the migration didn't run in the first place.

[kubasbimbas]

Hi, I’m facing the same issue. Immich app doesn’t start after the update.

[nebulon]

do you see the same error messages or something else, also have you adjust the config manually somehow?

[kubasbimbas]

Yes, I have the same errors...haven't changed anything.

Jul 06 20:46:50 Error: Invalid system config:
Jul 06 20:46:50 - [ffmpeg.acceptedAudioCodecs.2] Invalid option: expected one of "mp3"|"aac"|"opus"|"pcm_s16le"
Jul 06 20:46:50 at buildConfig (/usr/src/app/server/dist/utils/config.js:121:19)
Jul 06 20:46:50 at async /usr/src/app/server/dist/utils/config.js:60:26

[SansGuidon]

Fix found thanks to Claude Sonnet. The issue is that Immich v3.0 renamed the ffmpeg audio codec libopus to opus, see https://immich.app/blog/v3-migration, but the persisted config file (/app/data/immich.json) still contains the old value. Config validation crashes the server before migrations can run.

One-liner fix:

cloudron exec --app <APP_ID> -- sed -i 's/"libopus"/"opus"/' /app/data/immich.json

Then restart the app. The schema drift warnings resolve themselves once the app starts successfully and migrations run.

[james]

Hello @sansguidon
Thank you very much for looking into this and also providing a solution.

[SansGuidon]

@james all credits to Claude here

[BitEater67]

Also thank you for this solution.

[SansGuidon]

I wonder anyway how it happened to break for some users only?
And if a permanent fix should be integrated in the official cloudron package?

[BitEater67]

@SansGuidon .. especially when one had never not touched anything on that config file.

[jdaviescoates]

@SansGuidon said:

I wonder anyway how it happened to break for some users only?

My guess: the non effected users app had enough RAM to successfully complete the migration