| Summary: | Series of AVIs imported with the same (incorrect) time | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Gerald Pfeifer <gerald> |
| Component: | Import-PostProcessing | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles |
| Priority: | NOR | ||
| Version: | 1.7.0 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 2.1.0 | |
Same problem that https://bugs.kde.org/show_bug.cgi?id=229543#c3 Fixed in 2.1.0... Gilles Caulier |
Version: 1.7.0 (using KDE 4.5.5) OS: Linux When important a series of AVIs intermixed with JPGs and using the {date} specified for the filenames, many (though not all) of the AVIs end up with the same time and thus filenames like 20101220T103050-1.avi, 20101220T103050-2.avi, 20101220T103050-3.avi,... This first happened when importing from a Sea&Sea 2G camera, but I also could reproduce the effect when importing from a local file system. Interestingly, using a subset of the full data set in the latter case, some AVIs got different times, that is, the number of conflicts went down -- though looking at the result in Digikam, the "created date/time" display is different in all cases, so it's really the important which is broken, not the data. My impression is that this may be a memory corruption or uninitialized variable issue in the code. In several cases the date uses als Reproducible: Always Steps to Reproduce: 1. Import a series of AVIs and JPGs where several AVIs have been taken in a row without JPGs in between. 2. Automatically create filenames using the {date} specifier. Actual Results: Several AVIs in a row will feature exactly the same date and time in the filename, differentiated by appending -1, -2, -3,... only. Expected Results: Use correct recording time for the filename. The view of the imported Album in digikam shows the correct recording times, so it's there, just not used properly.