https://bugs.kde.org/show_bug.cgi?id=426497
--- Comment #4 from Johannes Nieß <li...@johannes-niess.de> --- 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. -- You are receiving this mail because: You are watching all bug changes.
