Incorrect tags assigned

I have a weird problem that I can’t wrap my head around. I have pictures that show tags that are neither in the picture itself (as far as I can tell) nor in the sidecar. Not only that, but it’s not handling the who hierarchy on two of the tags.

exiftool shows what I expect to see. photostructure info shows what’s in the UI.

I had photostructure rescan the file a couple times, no change.

I will send the image and sidecar to you, can you help with my sanity please?

From the image I assume there aren’t any duplicates detected for that image? I chased the same thing a while before I noticed that a duplicate had been found that had erroneous metadata.

No duplicates… However, I’ve just done some experimentation, and there is definitely a bug here.

test 1: create a new docker container, the folder being scanned only has the 1 picture (plus xmp). So library of 1 picture only. It mostly does the right thing (I say mostly, because I don’t know why it’s duplicating tags - but at least they’re all “who” and there is no phantom tag):

test 2: create a new docker container, with 2 pictures (plus 2 xmp). So a library of 2 pictures. There is where things go bad. It looks like the tags from the first picture are bleeding onto the second picture?

The first (new) picture is mostly ok (again weird issue with the who tag):

The second picture (the same picture as first test) now has messed up tags:

Now you’ll notice there are similarities in the filename. That’s by accident, and the pictures are completely different. Not sure if it’s because of the filename, or there is some sort of bug with variables not getting reset between pics.

I can email both pics to help reproduce.

UPDATE

test 3: renamed the first picture DSC_0196.jpeg to DSC_0195.jpeg, and repeated test 2. Tada! No tags carrying over from the first picture to the second picture. So my guess there is some sort of inference going on if the picture names look similar?

I’m sure “the man” @mrm will chime in and know all the facts…

I just find it interesting that all your examples have a:

/ps/Library/… path AND a //HCzetMSzL path

That looks like maybe a Volume ID or something. I’m assuming you didn’t create that “on purpose”.

I’m probably going down a rabbit hole and don’t mean to derail things, just found it of interest.

I noticed that too… I thought that particular bug was fixed in beta.10

Volume id shows as a tag

Ok, I have worked around this bug by renaming any photos with deceivably similar names… I had several dozens of them, with trial and error I think I got them all. I guess this bug forced me to actually clean up my junk a bit, probably a good thing in the long run.

Still feels like a bug though @mrm. The zip file I sent to the support email should make it very easy to reproduce.

hey… I see this item in the (un)release(d) notes for beta.13 points to this thread. So I guess @mrm figured out the issue. I was worries I was being ignored since @mrm did not put the eyeballs emoji on my post :slight_smile:

matchSidecarsFuzzily : set to false to disable [fuzzy sidecar matching]

Thanks for sending in the example!

Unfortunately, a bunch of software will write both sidecars and images with -N And -edit or -edited suffixes to mean a variant of the same image, including Google Takeout sidecars.

I’ll add a setting so you can disable this fuzzy matching in beta.13.

Edit: derp, I wrote this reply yesterday and I guess my internet hiccuped when I clicked send: it was still a draft…

1 Like

Yeah, I have no idea how I ended up with -n pics that are not at all related to the pic without that suffix. Weird. Thanks for the new option!

…so did I… :cry: I’ll poke at it after beta.13 is out.

And just to link related topics: Creation Time, Formatted Time, Total Confusion; or: Google Takeout Sidecar Files Are Misnamed - #16 by tmeitner