https://bugs.kde.org/show_bug.cgi?id=505023
Randall Rude <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REPORTED |CONFIRMED CC| |[email protected] Ever confirmed|0 |1 --- Comment #1 from Randall Rude <[email protected]> --- I reproduced this on both git master and my distribution-installed version 5.12.0. Willem, are the images all lacking a date/time in the file header, and do you have the "Trust image dates" option enabled? This is easy to reproduce with this image from the demo (which lacks a date/time in the EXIF header): $ exif demo/spiff.jpg | grep -i Date $ mkdir 505023 $ cp demo/spiff.jpg 505023/ # This test only works if the file has a non-zero fraction of a second in the modification time: $ stat 505023/spiff.jpg | awk '/Modify/ { print $2, $3 }' 2025-09-14 10:09:10.159101596 $ kphotoalbum --db 505023/ # create the new database # Select "Maintenance/Display images and videos with incomplete dates..." # Select "Search for images and videos with a valid date but an invalid time stamp" # Click OK - kphotoalbum doesn't find any images because the in-memory timestamp matches the files modification timestamp # Close the dialog, save the database, and exit kphotoalbum # The file date was read from the file's modification time but does not include the fractional seconds: $ awk '/startDate/ { print $3 }' 505023/index.xml startDate="2025-09-14T10:09:10" $ kphotoalbum --db 505023/ # reopen the database # Repeat the steps - kphotoalbum reports (for my copy of the image): spiff.jpg: existing = Sun Sep 14 10:09:10 2025 new..... = Sun Sep 14 10:09:10 2025 The difference is the fraction of the second read from the file's modification time which is not displayed to the user. -- You are receiving this mail because: You are watching all bug changes.
