Suggestion: More flexibility/consistency on tags/albums when uploading duplicated files

[AMarcedone]

First of all, thanks a lot for the great software!

Imagine I have the following folder structure, where essentially a file is copied in multiple subfolders (maybe I have a photo in its own album/folder and then in a BestOfYear album).

- folder1
    - A
        - x.jpg
    - B
        - x.jpg
- folder2
    - x.jpg

If I do immich upload --session-tag --folder-as-album FOLDER --folder-as-tags folder1, I would expect to end up with a single photo (x.jpg) be part of two albums (A and B) and tagged with folder/A, folder/B and the session tag.
Instead, the second time the photo is processed (as part of the same command), it is considered a duplicate and so it ends up being in only one album with only one folder tag and the session tag.

If I then (i.e. x.jpg is now already on the server) do immich upload --session-tag --folder-as-album FOLDER --folder-as-tags folder2, the photo is now added to album folder2 (so it is now in a total of 2 albums) but does not gain any new tags (neither the folder2 tag nor the second session tag).

Is this the intended behavior? I honestly find it confusing and counter-intuitive (although it seems that, at least for session tags, this is intended #810 ). I personally would want to end up (after both commands) in a situation where my photo on the server is part of 3 albums and has 5 tags (3 folder tags and 2 session tags). Or more generally have some command line options to control this behavior (e.g. --on-duplicate {MERGE|OVERWRITE|IGNORE}{TAGS|ALBUMS|BOTH}).

I have some (simple but not fully tested) change in my local fork that does the former (i.e. all albums and tags are uploaded, no config option), but I would be open to making a PR (either for the simple change or the configurable version) if people would find this useful.

[kuzyn]

I totally agree. I have multiple folders which contains duplicate photos, however the tags are never applied on the second images, which is very confusing. Same with the --folder-as-album flag.

@AMarcedone would you mind putting your fork on GH?

[kuzyn]

This also seems to be linked with #990 and perhaps #1131. Since the tagging happens at the end, maybe the folder names need to be written in a sidecar file while processing, then uploaded/merged at the end.

[filipcoja]

uppppp

[Jakeler]

I completely agree. For me duplicates are mostly from unsorted folders which contain everything of a device, while the same files are partly in more specific (events) folders. It would work well if it just applies all tags.
Right now it's basically random what folder is discovered first and I lose a lot of information if it's an unsorted one. The processing order should be a implementation detail and not change the outcome.

For session tags it's a different topic, it's a constant value and therefore a problem if applied to too many files.
Duplicates (same filenames) can only be on different paths, so it will generate new/unique tags - these add information and can be easily deleted afterwards if not relevant.

Just tested the tags via sidecar implementation (#1131) and that's no solution in the current form. According to the logs it shows "tags applied" on all duplicate paths, but it seems to overwrite the sidecar data, only the last discovered file/tag is uploaded.

Also I tried the update metadata feature (piffio@f5cb5a6, no PR from @piffio yet) and that actually solves this! It just goes over each file, and applies the current path as tag. A good solution if you already have the files in immich and missing tags.

Still it would be nice to fix it for the initial upload. Please @AMarcedone push your change and open a PR. I'm happy to test it.

[kuzyn]

I vibe coded something today that fixes this issue for my local build and allows for re-tagging of duplicates and uploaded files.

I feel a certain negative ambivalence about AI stuff and do not want to pollute or diminish the conversation, but the "fix" seemed quite small actually: let immich deal with the duplicate on the back-end, that way tags are always updated, and proactively call uc.manageAssetTags. The other changes are mostly just logging.

I'm attaching a patch file for anyone to peruse or test. I can eventually create a PR but I will be moving for the next few days.

0001-fix-apply-albums-and-tags-to-duplicate-files-1069.patch

[AMarcedone]

Hey all,
sorry for the late reply, I have been busy/travelling lately, and won't have time to really work on this in the next couple weeks.
The code changed a bit since I last touched it, but I rebased and here is what I got #1294
It should work at least in the simplest case.

The approach is similar to @kuzyn's patch, maybe a bit more concise.

[piffio]

I completely agree. For me duplicates are mostly from unsorted folders which contain everything of a device, while the same files are partly in more specific (events) folders. It would work well if it just applies all tags. Right now it's basically random what folder is discovered first and I lose a lot of information if it's an unsorted one. The processing order should be a implementation detail and not change the outcome.

For session tags it's a different topic, it's a constant value and therefore a problem if applied to too many files. Duplicates (same filenames) can only be on different paths, so it will generate new/unique tags - these add information and can be easily deleted afterwards if not relevant.

Just tested the tags via sidecar implementation (#1131) and that's no solution in the current form. According to the logs it shows "tags applied" on all duplicate paths, but it seems to overwrite the sidecar data, only the last discovered file/tag is uploaded.

Also I tried the update metadata feature (piffio@f5cb5a6, no PR from @piffio yet) and that actually solves this! It just goes over each file, and applies the current path as tag. A good solution if you already have the files in immich and missing tags.

Still it would be nice to fix it for the initial upload. Please @AMarcedone push your change and open a PR. I'm happy to test it.

Hello, and thanks for tagging me

In the recent months I've moved my focus on other self-hosted related projects, but if there is still interest in the "update metadata" feature, I can invest some time to put together a PR in the upcoming days.

[Jakeler]

Thank you all!
So the two patches are indeed very similar, the exact same 3 line change and duplicate condition at the end removed.
@kuzyn / claude adds a little more logging, which is nice to have.
Also adds a.Albums = append(a.Albums, advice.ServerAsset.Albums...) for which I don't see a reason logically and in testing, the albums are all updated correctly without it, so I would leave it out, as in @AMarcedone PR.

I did run the e2e testcases including the one I added for tags and it all passed. Imported larger folder structures and checked it manually, could not find any issues. Looks perfect for both local duplicates and updates on already uploaded assets!

@piffio Thank you for the quick response. Now that this simple change fulfills the same purpose I personally don't have a need for the feature anymore.
We can still think about adding a flag, although I don't see harm in merging/updating tags from folders by default. It's the same behavior on albums already, so it would be just consistent.

[piffio]

@Jakeler No worries, I just felt bad realising I had left things unfinished.
Happy to hear that it's no longer needed. If that changes at some point feel free to tag me back into the conversation