Bug 121460 - Album date average incorrect
Summary: Album date average incorrect
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Unclassified
Component: Searches-Dates (show other bugs)
Version: 0.9.0
Platform: Debian testing Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-06 11:17 UTC by Luc Sierens
Modified: 2012-06-27 11:28 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 0.10.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luc Sierens 2006-02-06 11:17:50 UTC
Version:           0.8.1 (using KDE KDE 3.5.0)
Installed from:    Debian testing/unstable Packages
OS:                Linux

In some cases the album date, as calculated by the [Average] button in the Album Properties dialogue, seems to be off by a substantial amount. 

As an example, I have an album with 6 images, all dated 2001-02-04 (both file date and exif date). The album date given by Digikam is 2005-03-28 (why?). When I use the [Average] button, the date I obtain is 2002-03-25!

I did some experiments to clarify this bug, and I suspect that it may have something to do with old entries (of removed images) remaining in the database.

 1. I copy the said 6 images to a new album : the new album date gives the correct average of 2001-02-04
 2. I add 1 image dated 2006-01-15 : now I get an average album date of 2001-10-20
 3. I delete the first 6  images : I still get 2001-10-20
 4. When I quit and restart Digikam, I get the warning that the datbase contains 6 images which are not on the disc. I let them be removed, and now I get the correct average date of 2006-01-15.

Of course this does not explain the wrong date of 2002-03-25 in the original album, but perhaps there is something similar happening there?
Comment 1 Tom Albers 2006-02-06 20:38:53 UTC
Op maandag 6 februari 2006 11:17, schreef Luc Sierens:
>  1. I copy the said 6 images to a new album : the new album date gives the
> correct average of 2001-02-04 2. I add 1 image dated 2006-01-15 : now I get
> an average album date of 2001-10-20 3. I delete the first 6  images : I
> still get 2001-10-20
>  4. When I quit and restart Digikam, I get the warning that the datbase
> contains 6 images which are not on the disc. I let them be removed, and now
> I get the correct average date of 2006-01-15.


You deleted the image outside digiKam. The database is wrong, you restarted 
digikam, database gets corrected, avarage is ok.  I can not fix this, you 
should not delete outside digikam.

> Of course this does not explain the wrong date of 2002-03-25 in the
> original album, but perhaps there is something similar happening there?


Creation date of the folder / first time digiKam detected the folder.

Toma
Comment 2 Luc Sierens 2006-02-07 18:48:48 UTC
> You deleted the image outside digiKam. The database is wrong, you restarted
> digikam, database gets corrected, avarage is ok.

I'm sorry, but in this experiment I did delete from within digiKam. There is a problem with digiKam not cleaning up the database. It does indeed get corrected by restarting the program.

Comment 3 Jens 2006-05-24 09:04:01 UTC
Hello,
I have a similar problem using 0.9.0-svn as of yesterday: I have some rather old pictures in one album (from 24/25 december 1989). One of them has a date that shows 14.5.1974. The "average" that digikam calculates in this case is 22.4.1968, which is obviously incorrect (much earlier than the first picture!). However, digikam did not (in my case) report any old DB entries that were removed and I did not change the album previously. Digikam 0.8.1 does the same thing.

The image dated 1974 does not have EXIF/IPTC tags, however the others do. When I add an EXIF tag (with exiftool) of DateTimeOriginal=1989:12:24 15:45, then digikam's "average" calculation goes to 23.12.1972, which is still incorrect.
If I then correct digikam's date of this picture (which is still at 14.5.1974), then the album average calculation shows 11.12.1991 ... later than the last picture in the album.

I don't get it ... =;)

Jens
Comment 4 Jens 2006-06-24 18:42:10 UTC
OK, I think I found this bug. The problem is this:

Digikam searches its DB for all files with a given 'dirid' (=album). But it has more entries in the database than pictures that are shown.

Example: Copy a directory with pictures and a "Thumbs.DB" file (from Windows) into the Digikam directory. The ThumbsDB is usually a lot newer than the images. Digikam will respect the date of this file when calculating the average album date (because it is in the SQLite database!), but not show it in the browser (so you can't see it from within Digikam, can't delete it and thus can't make Digikam calculate the correct date).

Solution: Digicam should only insert files in its database that are actually shown in the album browser. Otherwise confusion, hell and anarchy will result. ;-)

Jens
Comment 5 Marcel Wiesweg 2006-07-12 13:28:53 UTC
It's not so easy at a second glance.
There is the ioslave which is doing one part of the scanning (adding to db), there is the ScanLib which does the other part, and then there is again the ioslave which reads from the db.
Only the latter has a filter applied which is taken from the album settings.

So we could
- use the getAllFileFilter() in DIO::scan as well (which starts the ioslave scan)
- add filter support in ScanLib

But what if the user changes the extensions in the setup? What if the AlbumIconView adds an extension to the list? What if an extension is _removed_?

We could also think about why there is the massive code duplication of ScanLib + ioslave + AlbumDB. We could also postpone this to an undetermined point of time...

Comment 6 caulier.gilles 2006-07-12 15:03:13 UTC
Marcel, why not only filter the average computation method using only the current image mimetype ?

About the code duplication, i'm fully agree with you. Code simplification must be done at this place. I have'nt checked indeep the DB interface, but later 0.9.0 i'm favorable to perform a code polishing. I'm not sure if we can do it now, because there is already a lot of changes in digiKam. This is can be dangerous to touch DB interface before to release 0.9.0.

But this is just my viewpoint (:=)...

Gilles
Comment 7 Marcel Wiesweg 2006-07-12 19:09:09 UTC
Full ack, we cannot do this before 0.9.0.
I already thought about just filtering in the AlbumDB averageDate method. I will have to copy over the filtering code, which is a method or two, because it's only in the ioslave, but that's ok.
Comment 8 caulier.gilles 2008-12-04 16:09:21 UTC
Marcel,

With digiKam 0.10.0, this entry still valid ?

Gilles
Comment 9 Marcel Wiesweg 2008-12-04 23:24:30 UTC
Yes, this is 100% fixed in 0.10.0, and I think will never be fixed for 0.9.x
Comment 10 caulier.gilles 2008-12-05 06:18:17 UTC
Thanks Marcel. i close it for 0.10.0.

Gilles