https://bugs.kde.org/show_bug.cgi?id=267131
--- Comment #33 from mat...@mit.edu --- (Note to people about my previous suggestion: I am still experiencing database corruption with this method, so don't use it.) (In reply to Maik Qualmann from comment #32) > First, I'd clarify what you mean by "lost tags"? Did you lose tags assigned > to images? Or did you generally lose tags in the tag tree? > > The latter isn't possible at all, even if an empty or incorrect collection > is scanned. In that case, something must have gone wrong when copying the > database. > > Maik I don't have tags set to write back to files. It seems my initial assessment was incorrect. I tried to replicate this with both the UUID backup (what would happen if you just rsync'd your collection over) and the backup where UUID was edited to be a local 'Network' share (what would happen if you rsync'd then edited before starting digikam). The results were both as follows: - All pending image recognition tags such as pending face tags are lost. - Some amount of tags remain in the tag tree (either some or all; I don't have the original numbers since digikam 8.6 seems to segfault when X-forwarded, but if I had to guess I'd say all of the tags are okay on the contents of digikam4.db). - Digikam will start to Scan for New Files on its own, or you can stop/restart the process with Maintenance -> [X] All Albums -> [X] Scan for New Files. - As progress goes from 0 to 100% on the scan, the tags in the tag tree decrease from x -> 0, for whatever initial value of x they had. e.g. if tags MyTag (260) had 260 images, and the scan takes 6-10 hours for example let's say 8hr, then after about 4hr there will be MyTag (130) images left in that tag, and eventually 0. At the end of the scan, after ensuring the scan is complete (progress bar on bottom), almost all tags will be gone. Is this the same bug? Is there some step-by-step instruction for changing hard disks with digikam? -- You are receiving this mail because: You are watching all bug changes.
