Bug 149363 - Sort by date problem when copying images from an album to another
Summary: Sort by date problem when copying images from an album to another
Status: RESOLVED WORKSFORME
Alias: None
Product: digikam
Classification: Applications
Component: Albums-ItemsSort (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-29 23:59 UTC by Antonio E.
Modified: 2022-02-20 08:46 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antonio E. 2007-08-29 23:59:55 UTC
Version:           0.9.3svn (using KDE KDE 3.5.7)
Installed from:    Compiled From Sources

Today I've experimented a strange problem. I was organizing some albums, creating some new albums and copying photos from an album to others.

The problem more or less is this:

I had the folders A and B. Both containing pictures from the same month.

Now imagine that in A, I have pictures (sorted by date): a b c d e f, and in B 0,1,2,3,4,5,6,7,8,... and I copy some pictures from A to the folder B. The pictures from the folder A are of the same date and are in a date between picture 2 and 3 from B. When I go to B, I can see perfectly sorted by date and time the old B photos, but, the photos that I've just moved from A, are sorted by date, but inverse sorted by time.

So in B, I see something like: 0, 1, 2, f, e, d, c, b, a, 3, 4, 5, 6, 7, 8,...

So, somehow, it seems that the picture that were added the folder were only correctly sorted by day-month-year, but sorting in a reverse way by time.

The timestamps that the images displays seem correct.
Comment 1 Antonio E. 2007-08-31 10:02:53 UTC
I found a workaround for my problem, it was just to close digikam, copy the affected folder to a new one, remove any possible db file from there if it exists and start digikam again. That time the files are correctly indexed by date.

But the problem that I described when copying persists.
Comment 2 caulier.gilles 2007-08-31 10:07:40 UTC
Marcel,

Its sound like a problem in digiKam KIO slave ?

Gilles
Comment 3 Arnd Baecker 2007-08-31 11:45:08 UTC
I did not manage to reproduce this problem.
Gilles, did you manage to reproduce it?
If not, maybe it is something with the specific images?
Comment 4 Antonio E. 2007-08-31 12:03:33 UTC
I could reproduce the problem several times. The problem is that there's not enough debug info that I can attach. I anyone can tell me how can I turn a full debug on for this problem I'll recompile and attach the output.
Comment 5 caulier.gilles 2007-08-31 12:10:26 UTC
Antonio,

Copying files under digiKam is processed using a KIO-slave. Debug info can appear in a log file named "~/.xsession-errors

Just tail this file during a copy process and look if something wrong is reported.

Gilles
Comment 6 Antonio E. 2007-08-31 12:15:10 UTC
Thanks Gilles, this night or tomorrow morning when arriving home I'll make the test and report the results. As a note, the pictures where just JPGs taken with a Kodak DX4330, so with exif info.
Comment 7 Antonio E. 2007-09-01 13:32:48 UTC
Today I've recompiled 0.9.3 with the latest code from the svn. I've tried to reproduce the problem but this time everything worked as expected. I have no idea about what could cause that behavior, but it happened. Perhaps something temporally broken on my svn build? Well, as I can't reproduce the problem I resolve the issue. If I see this behavior again I'll try to attach all possible debug info.

Thank you Gilles and Arnd.

Antonio E.