Version: 3.1.1 (using KDE 3.5.8) Installed from: Gentoo Packages Compiler: 4.1.2 OS: Linux When I edit the time when an image was created in kphotoalbum (to correct it or to e. g. add the real creation time to a scanned image), only the year is saved correctly, the month is set to 1 and the day also to 1. I don't know if this is a kphotoalbum issue or a problem of the underlying exif libs, as the eixftime program behaves in the same wrong way: tobias@schleppi Ali $ exiftime -t a -v 2005y -v 5m -v 5d 01.jpg Image Created: 2005:05:05 01:00:00 Image Generated: 2004:05:05 01:00:00 Image Digitized: 2004:05:05 01:00:00 tobias@schleppi Ali $ exiftime 01.jpg Image Created: 2005:01:01 00:00:00 However, this is a quite annoying bug if one wants to get all images in the right order and one has to fix some dates.
What's the order that you have in the Settings->KPhotoAlbum->Metadata->Date->Fileds to write value to?
I never changed anything there; the order should be still set to the defaults. Here is it: EXIF Date -- stop -- Exif.Photo.DateTimeOriginal Exif.Photo.DateTimeDigitized
Just to mention it: with exiv2, it is possible to set the dates correctly here, e. g.: exiv2 -M"set Exif.Image.DateTime Ascii '2006:05:25 00:00:00'" 01.jpg
What happens if you run kphotoalbum like this: `LC_ALL=C KDE_LANG=en_US kphotoalbum`? Does it work?
Actually I got your report wrong. What's broken here, adjusting the image date in KPhotoAlbum (ie. changes made in the Annotation Dialog) or exporting it back to the EXIF (Maintenance -> Write metadata)? If the former, then this is a duplicate of bug 140030.
Wrinting the changes to the files didn't work. Aditionally, sometimes, kphotoalbum behaves strange with the dates of the photos: when sorting all images by date, some images still go wrong after having set the dates correctly, and the month and day are set to "1", although the EXIF headers contain the right date. Reading the date out of the EXIF header again sets the date correctly again. But I didn't manage to reproduce this behaviour somehow ... it just happens from time to time.
Hey guys, I managed to reproduce the bug: It happens to photos with a date in March, May, October or December. Whenever you select the category-editor for such a photo and cancel the dialog, it will ask you to lose the entered data (although nothing was changed). When instead of canceling the category editor you confirm the changes, the date of the photo is changed to 1. January of the same year. (You will see it if you open the dialog again.) There is no way to get the date back to March, May,... because the dialog does not seem to accept these months. Using the command line above `LC_ALL=C KDE_LANG=en_US kphotoalbum` solves the problem: the dates are no longer changed... Nevertheless i think this should be fixed, because at first you won't realize that photos are misplaced. Best regards, Alex
i guess it is the different typing in english and german: Jan = Jan; Feb = Feb,.... Mar != Mär Mai != May Okt != Oct Dez != Dec
Is anybody working on this? I'm pretty sure that "Silent Warrior" exactly describes the problem. Would be cool if this issue would be fixed :-)
Won't at least anybody remove the "unconfirmed" state from this bug?
I think you are talking about action that is done with KIPI plugins (found under the Plugins menu). They are external plugins and part of a different project http://www.kipi-plugins.org/. If this is the case you should report the bug to kipiplugins in bugzilla.
No, the bug did not happen when using some plugins but the normal "Annotate" dialog.
Seems to be working on kphotoalbum 4.1.1 and Ubuntu 9.10. (If I did the described steps correctly.)
Hi Tobias, sorry for not responding earlier. As I can't reproduce this issue on my box (I'm using Czech and English locales and trying to run KPA as `LC_ALL=de_DE.utf8 KDE_LANG=de_DE kphotoalbum -demo`), I'll close this report now -- I recall some patches going to that area of KPA. Tobias and/or Silent Warrior, please open this bug if the problem still persists (although I hope it is *really* fixed, even for you).