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):
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?
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
matchSidecarsFuzzily : set to false to disable [fuzzy sidecar matching]
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…