Bug 237810 - wrong date when renaming downloaded pictures
Summary: wrong date when renaming downloaded pictures
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: AdvancedRename-Import (show other bugs)
Version: 1.1.0
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-16 12:39 UTC by PCB
Modified: 2017-08-17 06:47 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 2.1.0


Attachments
Example Image (581.78 KB, image/jpeg)
2010-10-14 10:29 UTC, PCB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description PCB 2010-05-16 12:39:11 UTC
Version:           1.1.0 (using KDE 4.3.5)
OS:                Linux
Installed from:    Gentoo Packages

Digikam 1.1.0
Camera: Canon Ixus 70

I'm downloading the pics from my camera via Digikam and automatically rename them to their corresponding exif date, rename string is "[date:yyyyMMdd-hhmmss]". Now I have the problem that the new name is one hour in the future.
Example: Exif date is 20100516-120000, file name is 20100516-130000.jpg

Looks like I also found out the reason:
Living in Germany, we have summer and winter time (one hour difference). In the camera you can also toggle summer time, which adds +1h to the time. Error occurs only if summer time is switched on in camera, else not (even with same picture).

Extended Example:
1. Camera Time 11:00h
2. Toggle summer time switch in camera: 12:00h
3. Take picture. Exif time displayed for picture on camera is 12:00h
4. Download picture with Digikam. Exif time still 12:00h, picture named as 13:00h

As the file contains the right exif time after downloading, I would say this is a Digikam bug and not related to the camera, as Digikam also displays the right exif information, but obviously does something wrong when renaming the file.
Comment 1 caulier.gilles 2010-05-16 14:36:02 UTC
Try again with last digiKam 1.2.0

Gilles Caulier
Comment 2 PCB 2010-05-16 14:58:34 UTC
1.2.0 is not yet included in Gentoo, not even as unstable. I will try as soon as it is there.
Comment 3 PCB 2010-07-17 19:08:56 UTC
It has been a while... finally, 1.2.0 is included in the official Gentoo repository. Installed, started, downloaded some pics from my camera, problem still exists. 

Although EXIF information clearly states that the pic was made at, e.g. 18:04h, it is named xxxx-1904.jpg.

Yes, I know that Digikam 1.3.0 is already out there. Same problem as before, not included in Gentoo yet. But I doubt that the bug was already fixed there.
Comment 4 Andi Clemens 2010-10-01 22:52:32 UTC
Hi, 
can you provide us with an example image?
So that I can check the date token in the rename tool?

Andi
Comment 5 PCB 2010-10-14 10:29:29 UTC
Created attachment 52502 [details]
Example Image
Comment 6 PCB 2010-10-14 10:34:16 UTC
Attached an example image, although i don't know if this will really help. The file is as-is after downloading from the camera with digikam.

Rename string in Digikam was "[date:yyyyMMdd-hhmmss]".
Internal EXIF date is "2010:10:02 12:46:23".
File was renamed to "20101002-134623.JPG"

When examining the EXIF data in Digikam itself, it is displayed correctly, but not in DKs own download dialog.
Comment 7 Andi Clemens 2010-11-15 00:01:03 UTC
Hm, I tested this and it worked for me. Can you test with the latest SVN version, if possible?
Comment 8 PCB 2010-11-15 12:18:10 UTC
I wish I could... SVN-Digikam obviously doesn't like me...

I followed the instructions from
http://www.digikam.org/drupal/download?q=download/KDE4

But when calling cmake on the svn checkout of DK I get the following:
[...]
-- Found Kdcraw library in cache: /home/user/digikam/lib/libkdcraw.so
-- Found Kexiv2 library in cache: /home/user/digikam/lib/libkexiv2.so
-- Found Kipi library in cache: /home/user/digikam/lib/libkipi.so
[...]
-- checking for module 'libkdcraw>=1.1.0'
--   package 'libkdcraw>=1.1.0' not found
-- checking for module 'libkexiv2>=1.1.0'
--   package 'libkexiv2>=1.1.0' not found
[...]
--  libkexiv2 library found.................. NO
-- 
CMake Error at digikam/CMakeLists.txt:86 (MESSAGE):
   digiKam needs libkexiv2. You need to install the libkexiv2 (version >= 1.1.0) library development package.
[..]
--  libkdcraw library found.................. NO
-- 
CMake Error at digikam/CMakeLists.txt:86 (MESSAGE):
   digiKam needs libkdcraw. You need to install the libkdcraw (version >= 1.1.0) library development package.

Any ideas?
Comment 9 Andi Clemens 2010-11-15 12:50:57 UTC
You should also build these two libraries from SVN and install them, as described in the above link you mentioned.
Comment 10 PCB 2010-11-15 13:09:18 UTC
Oh, I did, although in a sub-directory of my home dir. But, as seen above, cmake did find them (/home/user/digikam/lib/libkexiv2.so) but is not happy nevertheless.
Comment 11 Andi Clemens 2010-11-15 13:15:02 UTC
Hmm I don't know if this will work, without installing. I'd suggest to do a backup of your system and then install the libs system-wide.

If it still doesn't work, try to remove the CMakeCache.txt file from the digikam SVN folder and then recreate it by calling 
'cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/usr/ -DCMAKE_CXX_FLAGS=-pedantic -DCMAKE_C_FLAGS=-pedantic -DCMAKE_BUILD_TYPE=debugfull'

or similar, depending on your needs.
Comment 12 PCB 2010-11-15 14:52:44 UTC
Ok, solved the local install compilation issues:
PKG_CONFIG_PATH=/home/user/digikam/lib/pkgconfig cmake -DCMAKE_BUILD_TYPE=debugfull -DCMAKE_INSTALL_PREFIX=/home/user/digikam -DCMAKE_LIBRARY_PATH=/home/user/digikam/lib -DCMAKE_INCLUDE_PATH=/home/user/digikam/include -DCMAKE_CXX_FLAGS="-O0 -g" -DCMAKE_C_FLAGS="-O0 -g" ..

Problem still persists, though:
File name    : 20101015-180906.JPG
File date    : 2010:10:15 18:09:06
Camera make  : Canon
Camera model : Canon DIGITAL IXUS 70
Date/Time    : 2010:10:15 17:09:06   <== this is the correct date and time
Tested verion of Digikam was: Version 1.6.0 (rev.: 1197241)

Can you give me a hint on where in the source I can find the code where it determines the name when renaming pictures while downloading? Especially the part where rename patterns like mine from above ([date:yyyyMMdd-hhmmss]) are evaluated. Perhaps I can try to do a little debugging...
Comment 13 caulier.gilles 2010-11-30 22:08:19 UTC
Andi,

Do you see comment #12 from PCB ?

Gilles Caulier
Comment 14 caulier.gilles 2011-08-04 14:31:52 UTC
Same problem that https://bugs.kde.org/show_bug.cgi?id=229543#c3

Fixed in 2.1.0...

Gilles Caulier