Bug 121460

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

> 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.

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

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

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...

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

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.

Marcel,

With digiKam 0.10.0, this entry still valid ?

Gilles

Yes, this is 100% fixed in 0.10.0, and I think will never be fixed for 0.9.x

Thanks Marcel. i close it for 0.10.0.

Gilles