Difference between collection types

[Paul Waldo]

Hi Gilles,

Yea, yea, I know... :-)  I store the sqlite file on a mounted samba share, so it looks local.  I just make sure that only one Digikam accesses it it the same time.

Paul
----- "Gilles Caulier" <[hidden email]> wrote:

> 2009/6/12 Paul Waldo <[hidden email]>:
> > Hi Marcel,
> >
> > The slow startup time seems to be DB related.  Just for fun, I moved
> the DB to a local drive.  The startup time was half or a quarter of
> the time with the DB on the NAS.  Also, I saw the CPU get pegged for a
> good bit of the time (yay!).
>
>
> SQlite do not support remote DB file hosted on NFS or Samba. It's a
> sqlite limitation. In digiKam setup dialog is clear. Look all tip
> words...
>
> Gilles Caulier
>
> >
> > I have no idea how sqlite accesses a DB on what it thinks is a local
> file, but this seems like quite a hint to me that I need to make the
> DB local.  Maybe Digikam could have a setting to make DB backups in
> the background...?
> >
> > Paul
> > ----- "Marcel Wiesweg" <[hidden email]> wrote:
> >
> >> A complete scan of 26994 pictures on 39GB, 99% JPEGs, took 12
> minutes
> >> and 20
> >> seconds in a short test while writing this mail. A normal
> application
> >> start
> >> uses <5s for the scan if no files are new. That's local harddisk.
> >> I dont know what is causing the huge performance drop over network
> >> storage.
> >> In 15h, 3.5s/picture, you could transfer 900MB of data for every
> >> picture over
> >> the network.
> >>
> >>
> >> _______________________________________________
> >> Digikam-users mailing list
> >> [hidden email]
> >> https://mail.kde.org/mailman/listinfo/digikam-users
> > _______________________________________________
> > Digikam-users mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users
> >
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Paul Waldo]

Hi Marcel,

I've had a chance to do a little more extensive testing.  Proper recognition of images already in the DB is spotty and there is no rhyme or reason (that I can see) as to what files are matched and which are not.  

Your supposition about inconsistent hashing is interesting.  I set all Image's modificationDate to null and reimported the album.  A spot check shows that the tags were migrated!!  I'd certainly like to keep my modification dates, but if this is the only solution, I suppose I can live with it.  Is there any other way to force a re-hash?

Paul
----- "Marcel Wiesweg" <[hidden email]> wrote:

> >
> > Hmm, dunno how they could be different.  The two collections point
> to the
> > same place, the only difference is that one is a symlink:
> >
> > ls -ld /home/paul/Pictures/camera
> > lrwxrwxrwx 1 paul paul 12 2009-06-08 11:25
> /home/paul/Pictures/camera ->
> > /mnt/camera/
>
> That means something would have changed in the way the hash is
> generated. I
> dont like that. I can only think of a different exiv2 version
> providing
> different binary metadata. I did not come across this so far.
>
> If you set modificationDate (in the Images table) of 33963 to NULL and
> start
> digikam - which triggers a full rescan of an image - is the hash then
> 8e3 or
> fe8?
>
> Marcel
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

> Hi Marcel,
>
> I've had a chance to do a little more extensive testing.  Proper
> recognition of images already in the DB is spotty and there is no rhyme or
> reason (that I can see) as to what files are matched and which are not.
>
> Your supposition about inconsistent hashing is interesting.  I set all
> Image's modificationDate to null and reimported the album.  A spot check
> shows that the tags were migrated!!  I'd certainly like to keep my
> modification dates, but if this is the only solution, I suppose I can live
> with it.  Is there any other way to force a re-hash?

No there is not. You dont lose anything, because this is the modification date
as taken from the file system. It is used to see if a file was changed since
the last scan and it will be updated again while scanning.
It's not creation or digitization date imported from the exif data.

Marcel
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users