| Summary: | Inconsistent metadata in pictures and database when some albums are read-only | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | MarcP <iwannaberich> |
| Component: | Maintenance-Metadata | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | caulier.gilles, iwannaberich, metzpinguin |
| Priority: | NOR | ||
| Version First Reported In: | 8.4.0 | ||
| Target Milestone: | --- | ||
| Platform: | Appimage | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
MarcP
2018-10-10 10:57:00 UTC
What did you expect ? That DK write metadata in image even if file are read only ? We will never do that, even if it's possible technically. So for me it's not a bug, but a normal behavior. Gilles Caulier No no, if a library is read only, of course there's no way of changing that. I meant that at least showing a warning when a file could not be modified would be helpful. I understand digikam is not responsible for other people's changes in a picture library, but it currently works very well in doing so, except for minor issues like this. A more simple solution I propose would be to automatically re-scan the picture metadata after a file has been modified. Such option already seems to exist (Settings, Configure digikam, Metadata, "Rescan files when files are modified"). This way, only changes that have been really applied will show in digikam, maintaining database-metadata integrity. So basically a Warning message + Metadata re-scan after changes. It is actually a duplicate of its Bug 391891. There are users who purposely set their images to read only to protect them from change. I do not think they want to see a warning dialog all the time, probably no notification either. Maik Well, yep, it's based on this bug, but here I focus on the fact that the library can differ from the picture metadata because digikam (and users) thinks these changes have been applied when they have not. For instance, imagine one user correcting the date on one picture. He hits on apply, the change is reflected in digikam, so he considers the job is done. But internally, digikam found the file is read-only, didn't apply any changes, and shows mismatching information that won't be updated to other people (which might use digikam or other software to view those pictures). As I said, just re-scanning metadata when files have been modified should solve this issue. Plus the read-only warning (or greying-out the OK and Apply buttons, I don't know, but at least some feedback would be helpful). No, it does not work. For example, I have all my tags and all changes only in the database and also changed date. Therefore, re-reading and cleaning up the database before re-reading is also optional. And re-reading the metadata after each write would push performance into the basement when writing lots of metadata. For this they have the maintenance tool to later write the missing metadata into the images. Maik Of course, re-reading the metadata from the images after changes should only occur if the option is checked (I suppose now it only detects external changes, right?). I actually manually re-read pictures after changes since date changes are not reflected in windows until I do so (bug #391440). It's a small price for keeping metadata-database consistency. Also, when writing large amounts of pictures, digikam already shows a warning. (PS: I don't get what you mean by "push performance into the basement") After 3 weeks of work, i finally completed the compilation of AppImage using Qt 5.11.3 + QWebkit 5.212. New 6.1.0 pre-release AppImage bundle can be found here (64 bits only for the moment) : https://files.kde.org/digikam/ Please check if this bugzilla entry still valid. Thanks in advance Gilles Caulier digiKam 7.0.0 stable release is now published and now available as FlatPak: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Thanks in advance Gilles Caulier Behavior still present. Digikam is not aware if a file is read-only when writing metadata and just assumes it has been written correctly. @MarcP, digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier Marc, What's about this file using current 8.2.0 AppImage Linux bundle ? It's reproducible ? https://files.kde.org/digikam/ Note: bundle is now based on Qt 5.15.11 and KDE framework 5.110. Thanks in advance Gilles Caulier Hi all, The digiKam 8.4.0 Appimage bundle pre-release is now based on last modern frameworks Qt 6.7.0 and KDE 6.2.0. File can be downloaded at usual place : https://files.kde.org/digikam/ Take a care : the bundle is named with the suffix "-Qt6" not "-Qt5". This bundle is compiled under Ubuntu 22.04 and require a Linux with GlibC version >= 2.35 to run. Can you reproduce the dysfonction with this version? Thanks in advance Gilles Caulier Hi, yes, I think this behavior has not changed. If a collection is not online, we now have an error icon for the respective collection in the album view. We could also show this icon if the collection is online but not writable. For each album individually this would probably be bad for performance reasons with network collections. Maik |