[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 :)

[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.

[earlsrock]

You guys are so awesome. Love this product.

Slapping my head that I didn't call out the duplicate function as a possibility. Yes - similar to running duplicates against the trash and an external library. Checking the stored hash of the missing object in trash against the "new" image should work well.

Couple of thoughts though:
1: The "Keep" image would need to sync metadata and album ownership of the object in trash to make this effective. Which I believe is already an ask for duplicates - we are just now leveraging trash as well. (#13851, #10262, and in part #10206).

2: It's documented in the FAQ that there are limitations of duplicates for External Libraries - namely that it only runs on Upload Libraries. This would open up duplicates to also be a function of External Libraries (which I didn't see a specific request for).

3: I can see this leading to a request very quickly for duplicate detection between different external libraries. Just calling that out. Not that it's a bad thing.

Thanks for all you do!

[etnoy]

That was only my very first test, the UI will need to be modified in the ways you mention. Also, for external assets we don't compute the hash so we'll have to go by smart search.

This is the easy path though, there are lots of edge cases. Files can be moved several times, assets can be trashed, and so on. But I think this is the way to go

[earlsrock]

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.

[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