Bug 231585 - empty date for mod files
Summary: empty date for mod files
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: AdvancedRename-metadata (show other bugs)
Version: 1.1.0
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-21 21:46 UTC by Benoit DUMONT
Modified: 2022-02-01 06:42 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 1.3.0


Attachments
screenshot of the missing date problem (140.74 KB, image/png)
2010-03-21 22:20 UTC, Benoit DUMONT
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Benoit DUMONT 2010-03-21 21:46:43 UTC
Version:           1.1.0 (using 4.3.5 (KDE 4.3.5), Mandriva Linux release 2010.0 (Official) for i586)
Compiler:          gcc
OS:                Linux (i686) release 2.6.31.12-desktop586-1mnb

I have a JVC camera that generate video mpeg file that are named MOV000.MOD
I used before 1.0 release to download those files having the "on the fly renaming rule" that put the timestamp.
Since 1.0 release, the date is empty for all those type of files.
As a consequence :
- all files are trying to be renamed .mod so that the first file become hidden and the rest are -0.mod
- it seems that the history download is not kept so that all those files are always declared as new even if I already downloaded them.

The strange thing is that once downloaded. If I try to rename them, the date is then correctly feeded with the file name.
Comment 1 Johannes Wienke 2010-03-21 22:01:07 UTC
Can you provide a small test file?
Comment 2 Benoit DUMONT 2010-03-21 22:20:16 UTC
Created attachment 41820 [details]
screenshot of the missing date problem
Comment 3 caulier.gilles 2010-03-22 09:36:08 UTC
Sound like a problem in Advance Rename tool which do not find mod metadata with Exiv2 (which is normal, like mod format is not yet supported).

At least file system date must be used there. Andy ?

Gilles Caulier
Comment 4 Andi Clemens 2010-03-24 07:29:57 UTC
Gilles,

this is the problem I mentioned some months ago :-) Somehow metadata is not visible anymore in the import tool. It worked for digiKam 0.10 and even 0.11, but in 1.0.0 it is broken. AdvancedRename works fine in AlbumUI and BQM, but not in Import, since the metadata is gone / not read.
Maybe I need to call other methods in ImportUI than the ones from DMetadata and ImageInfo?
Comment 5 Benoit DUMONT 2010-03-28 22:01:06 UTC
Do you still need a small test file ?
I beleive not as the bug is identified but I will provide if you ask me.
Comment 6 Andi Clemens 2010-05-23 13:17:36 UTC
If you can provide a test file, I can take a look at this problem again...
Comment 7 Benoit DUMONT 2010-05-27 22:16:37 UTC
I fact you could take any video file that has no exif or XMP tag defined.
I tryed to attched a sample file but even very small film takes 2 Meg.
to generate a test file, you could do something like 
echo "toto" > example.mod
and declare the extention "mod" as beeing a video file.
I fact any video file will have this issue as the issue is more related to the fact that when no exif date are found it doesn't default to the creation date of the file.
Comment 8 Andi Clemens 2010-06-03 21:54:24 UTC
SVN commit 1134267 by aclemens:

Tripple-check datetime information in the parser. It should have been set already be the
calling instance, but somehow it fails for CameraUI now.

BUG:231585

 M  +28 -3     dateoption.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1134267
Comment 9 Andi Clemens 2010-06-03 22:19:38 UTC
Should work fine now, at least it does for my Nikon D50.
The fix will be in the next digiKam release (1.3.0), coming this weekend.

If it is still not working for you, feel free to re-open the bug.