https://bugs.kde.org/show_bug.cgi?id=426938
--- Comment #1 from Kurt Granroth <granr...@kde.org> --- It figures that after months of seeing this with no known cause or workaround, I have potentially found both literally minutes to hours after posting this bug. Maybe a bit of rubber duck debugging. Anyway, the light bulb went off initially when doing an Import->Add Images rather than a copy-and-auto-scan and seeing that not only were all of the dates correct, but it also took a decent amount of time to import. Why so much time? Well, these files are quite large -- some are multi-gigabyte and it simply takes notable time to copy that much data on a mechanical HDD. Oh... could that be it? I did a test were I did a manual copy of some video files into another directory and noticed that MacOS reports the 'creation time' of the files as 'right now' for the duration of the copy and only sets the actual 'creation time' to match the original AFTER the copy is completed. So could this be a race condition? Is Digikam maybe monitoring the albums/directories on a set polling basis and could it simply be encountering the "wrong date" video files BEFORE the copying is completed? Seems plausible. With that in mind, there is a potential workaround (not counting the Import) and that is to run Tools -> Maintenance -> Sync Metadata and Database on the given albums after everything is successfully copied over. I make sure the sync direction is "From image metadata to database". That appears to work like a charm. Another option might be to disable auto-scan and just remember to Tools -> Scan for new items regularly. If it really is just a race condition then it is still a bug (shouldn't be adding the file until its state has solidified) but maybe that's not a bug worth fixing since it's such an esoteric case and has known workarounds? -- You are receiving this mail because: You are watching all bug changes.
