-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Read-only external library metadata edits silently fail #10538
Comments
Its funny, I've been 'reproducing' this bug for a few days now and pulling out may hair in the process. I agree, that there should be some indication on the external library, or on the file. Maybe even gray out the options so the user knows whats going on. The silent fail felt very random. I'm just glad its not me 😄. EDIT: It did. |
I also seem to have silently failed here. I havent confirmed issue, but will verify later. |
What seems to be a bit weird is that when you add new tags, those will be saved, even tho xmp writing fails. However changing the date or the location straight up doesnt work. It will be nice if the behavior is consistent. |
Does this mean the tags go in the database? 🤔 |
The reason that happens is that extracting date or location from the file metadata overwrites what is in the database because an asset can only have one date or location, which doesn't apply to tags. |
It should apply to tags as well. Tags are written to xmp and replaced on a subsequent metadata extraction. |
FWIW I am having this issue with tags on my RO external library
|
can the xmp files or whatever be written somewhere else? |
+1 can the xmp files or whatever be written somewhere else? |
They're sidecar files, storing them somewhere disconnected from the media doesn't really make sense. |
The bug
This has been discussed several times before, but there is an unintuitive behaviour where if a user edits metadata of an asset in an external library that's mounted as read-only (say by forgetting it's read-only or believing the edit would be stored in the database or generated files) then the edit silently fails.
A simple solution that came up in discussion is to issue a generic asynchronous popup to the client saying "failed to save metadata for <asset filename>: file system is read-only" or similar (and the log should mention "read-only" too).
The OS that Immich Server is running on
Debian 12
Version of Immich Server
v1.106.3
Version of Immich Mobile App
n/a
Platform with the issue
Your docker-compose.yml content
Your .env content
Reproduction steps
Relevant log output
Additional information
No response
The text was updated successfully, but these errors were encountered: