https://bugs.kde.org/show_bug.cgi?id=463378
--- Comment #10 from Metal450 <metal...@gmail.com> --- (In reply to Maik Qualmann from comment #7) > Giving a warning every time isn't really practical. So currently the software has that toast UI, i.e. "Updating database - process is done." I was thinking a similar pop-up when applying from database to file, i.e. "Writing files from database - xxx items may not have been successful." Something like that. > On the one hand we don't get an error message from Exiv2 in this case. But the digiKam catalog already knows the files have that particular metadata tag: https://jiij.cc/snaps/2022-12-25_09.17.56.png. So it shouldn't need an explicit error for Exiv2, right? Just knowing that "we're writing tags to a file" and "that file has the XP* tag" is enough to infer that "this file may not be written correctly." > On the other hand, we would have to read all the metadata of the images to > determine which ones contain the XP* tags, which would lead to a severe loss > of performance, especially on network drives. Why would it need to read all the metadata from files again? The catalog clearly already knows the metadata is there (that's how it knew that tag existed in the first place, and made it available to be unchecked in the "Captions" pane). So no need to re-read from disk again...? > We can actually write the XP* tags with ExifTool in the same step as the > modified metadata container. In a first patch we will generally remove the > XP* tags when writing new tags. > add write support for XP* metadata when Exiftool writing is enabled > By default, the legacy XP* metadata is disabled in a new config. So to clarify, to avoid the issue, I need to explicitly enable "Settings->Metadata->Delegate to ExifTool all backend operations to write metadata to files"? If so, any other ramification/side effect, besides this bug not occurring? -- You are receiving this mail because: You are watching all bug changes.
