[Feature] Move detection in external libraries

[Electr0Fi]

I have searched the existing feature requests to make sure this is not a duplicate request.

• Yes

The feature

In the External Libraries documentation (https://immich.app/docs/features/libraries) it states:

If you add metadata to an external asset in any way (i.e. add it to an album or edit the description), that metadata is only stored inside Immich and will not be persisted to the external asset file. If you move an asset to another location within the library all such metadata will be lost upon rescan. This is because the asset is considered a new asset after the move. This is a known issue and will be fixed in a future release.

Is there currently a timeline when this known issue will be fixed?

It would be great to finally be able to move and modify files in an external library and not have to rescan, regenerate thumbnails and re-run face detections on thousands of assets each time.

Platform

• Server
• Web
• Mobile

[mmomjian]

We should probably reword that. It might be a while and we have no active ETA/plan.

[Electr0Fi]

Thanks for the quick reply!

Is there any way this could get prioritised over other features and added to the roadmap?

I know the whole idea is for Immich to handle all images via the it's upload function, and the support of External Libraries is just a nice-to-have, but it seems that a lot of people use them and would greatly appreciate this feature.

[mmomjian]

We don’t plan to do that at this time. Most people are not regularly moving the files in their external library, as far as I know.

[Electr0Fi]

Okay, that's fair.
Thanks for reply and your contributions to the project :)

[DeltaTango69]

We don’t plan to do that at this time. Most people are not regularly moving the files in their external library, as far as I know.

As long as no faces are shared via partner sharing, this is the only way with the external library

[bo0tzz]

@etnoy is this something you're planning to work on? If not we should probably remove that line from the docs.

[earlsrock]

I understand it being low priority, but this would be super-helpful in the way I use Immich.

[etnoy]

I'll be honest, I have no idea how this can even be done in a reliable way. It's edge cases upon edge cases. If you can point me to an open source software that does this, please point me to it.

[alextran1502]

@earlsrock for external library, it is designed for users that curate the library that fits their wants and needs. So there will be cases where the assets are put into multiple directories. Since the structure of the directories is important to such use case, we don't want to application to dedup based on the file content there

[etnoy]

Just curious - why no hash on external assets? potential size of external locations, db impact, general resources, other? Seems like it wouldn't be a bad thing to do.

We're actually looking into changing this behavior and also hashing external assets. Maybe it will happen, maybe not. If we do, that's an even better way to do move detection than basing it on fuzzy smart search

[ssynnes]

I think that using hash would be a wonderful solution! What about:

1. Start storing file hash for all Immich assets
2. When importing new images, start by computing the file's hash
   2a) If the hash exists in a deleted asset, then replace the path of the delete immage by that of the new image and recover it to the database
   2b) If the hash exists in the asset database, then check if the file exists. If not, then update the file location.
3. If not 3a nor 3b, then run a normal import

[etnoy]

I think that using hash would be a wonderful solution! What about:

1. Start storing file hash for all Immich assets
2. When importing new images, start by computing the file's hash
   2a) If the hash exists in a deleted asset, then replace the path of the delete immage by that of the new image and recover it to the database
   2b) If the hash exists in the asset database, then check if the file exists. If not, then update the file location.
3. If not 3a nor 3b, then run a normal import

Yes, but please remember what Alex and I have pointed out already in the thread: you can't assume that a file is unique in an external library. It's highly likely that a user has the same file in multiple directories

[ssynnes]

True. Reordering 2b and 2a should take account for that. Then a an externally moved file (that is not already found missing by Immich) will get its location updated, rather than reinstating a deleted duplicate from trash.

Using folders to organize photos is a very commonly recommended operation, and if Immich could support this, it would give a smoother transition for new users and all users would be less vulnerable to accidentially loosing metadata. From the comment in the docs recited at the start of this tread, I read that this is recognized by the Immich team. Thanks for an awsome software!

[andreheuer]

Maybe as a short-term idea: what about supporting basic file operations (copy, delete, move) in the folder view for external libraries? That would (from my point of view) already fulfill a lot of use cases.

[maldimirov]

I wouldn't call this solution just shorterm. Yes it fixes the original issue. But it also is a great feature on its own standing.
I also use external libraries (obviously) and different kinds of file explorers that I use have the same downside - slow loading of image thumbs. So actually being able to move/rename files within Immich will greatly improve my UX and will make it so that I don't even have to rely on other tools and can do all the work within Immich.

[mbuzina]

If you setup your external library as rw (remove the ro in the docker-compose.yml file), immich will write an xml-sidecar file. Move this along with the file and immich should (haven't tried yet) get all tags from there. Does it write album and description info into the sidecar as well?

[keesjebal]

Nope. Most info is not stored in the sidecar file. Eg, 'taged as favo', albums and faces if is not part of the sidecar file.

[trecoool]

Pitching in to describe my very much hoped use case :

• i have 2 external libraries : albums and phone
• both get fed externally by syncthing :
  • albums are fed from folders i organize manually on my desktop and use a script that creates an immich album for each folder and add any photos in it to the album.
  • phone is a a sync of my phone photo folders

I would like to be able to move some photos from my phone folder to my album folders, which would free up space on my phone while keeping them intact in immich. These photos are potentially already added to an immich album and should stay in it as they are moved.

If this use case is feasible my immich setup would be complete 🤗

[maldimirov]

Btw, I have a similar setup with my wife. But my phone syncs to the same external library as my photo archive. So this way I can move photos within the same library and free up space on my phone memory. My guess is that when the Immich move funcitonality is ready, moving within the same ext library, would be easier (and may come sooner), than moving between 2 libs.

[trecoool]

Thanks for sharing! I'm worried you might be right with your last point 🥲

In my case i'm going to hope that it's just as easy to move between different libraries : my phone syncs its whole content through syncthing into primary storage in a single folder. Immich can accesses this whole folder through according external libs. For example whatsapp incoming photos is different library than camera folder. This can evolve over time, as different apps save to different locations in the phone. Also I don't want to keep this whole "complete phone" folder in the same folder i keep all my ordered memories 🙂

Do you have any work-around that kinda works in the meantime?
My phone is getting filled up and I don't know how to free space without loosing connection to immich db.
I have tens of albums shared with specific people, and if I break my db links, all albums will be borked 🥲