Created attachment 131612 [details] Screenshot SUMMARY Light table sometimes displays the wrong picture in comparison window. Seems to be connected to additional pictures created by external programs, e. g. GIMP, while Digikam is open and directory not rescanned manually (New pictures at end of list, not yet complying with sort order). Not seen with digikam 7.0. OBSERVED RESULT Mismatch between pictures in film strip preview and main comparison. EXPECTED RESULT Pictures selected in digikam main window displayed in all light table windows. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.2 ADDITIONAL INFORMATION
If you make a lot of external changes and expect digiKam to update it automatically, you can re-enable the option to monitor albums. The option is located in the digiKam setup under Collections. Maik
(In reply to Maik Qualmann from comment #1) > If you make a lot of external changes and expect digiKam to update it > automatically, you can re-enable the option to monitor albums. The option is > located in the digiKam setup under Collections. > > Maik The issue occurred with 'Monitoring albums' enabled.
I don't exactly understand how to reproduce it. Is the image that you are changing already open in the light table? There's one thing we changed about whether an image in the cache is still valid. The QFilesystemWatcher can no longer be used because it causes problems on other platforms. When loading from the image cache, we now check whether the change time and file size of the image are still appropriate in order to recognize an external change and to start reloading the image. An image that is already open in the view remains until the next load. Tests here with the new function did not reveal any problems, an external image change was definitely recognized. Maik
According to your description of touching this area, a bug in file selection logic seems to be likely. I didn't discover until today that the file change times of the offending JPG (not shown in the screenshot) and the intended JPG are identical (at least within the same second), probably by updating their rating in the same selection (and writing this meta data to files). I probably haven't figured out all the preconditions to reproduce it. I can't reproduce with differing file change times. While trying with identical file change times, an offending (cached?) picture was displayed for a split second but was then updated correctly. Another observation: While the first new picture of a digikam session immediately complied with sort order, the second one showed the "attached at the end" behaviour. My usual workflow is this: 1) Upload raws (*.NEF) from camera 2) Rating for pictures worth developing 3) "Open with" Gimp that starts Rawtherapee in the background 4) Saving the final Gimp output as JPG in the same directory as the raw file, often as ...-gimp.jpg 5) During this time Digikam stays open but is not touched 6) Closing GIMP and returning to digikam, the new JPGs are displayed at the end of the list (or filtered out), even when this isn't their position according to sorting. I could not reproduce this after a manual directory rescan and pictures being sorted. 7) Comparing NEF ad JPG on the light table. 8) The offending picture in the light table main view is the JPG related to the raw displayed after the selected picture in digikam's main window. It also was the last picture I developed before this one.
I haven't been able to reproduce this bug, relevant code has been touched since then and I have not seen it again in the last 16 months while keeping digikam up to date. Depending on your style of defect management, you might want to close it as "nothing to work on" or keep it open as a weak hint of problems in this area. I can agree to both.
Thanks Johannes for your feedback. I close this file now...