[digikam] [Bug 479711] Find new items at startup very slow (Mac)

2024-01-12 Thread bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=479711

--- Comment #3 from at...@electropositive.net ---
I've enabled debug and console logging thank you.

Running digikam like this, and adding files from a local HDD, the find new
items got to 100% quite quickly, but it's stuck on 100% now and presently there
are a lot of these in the logs spinning by.  One for every file I assume.

```
digikam.metaengine: Loading metadata with "Exiv2" backend from
"/Volumes/5TB/pictures/Family/Masters/2015/January/Trip to
Whangarei/_MG_5465.CR2"
digikam.dimg: "/Volumes/5TB/pictures/Family/Masters/2015/January/Trip to
Whangarei/_MG_5465.CR2" : "RAW" file identified
digikam.database: Adding new item
"/Volumes/5TB/pictures/Family/Masters/2015/January/Trip to
Whangarei/_MG_5465.CR2"
digikam.database: Recognized
"/Volumes/5TB/pictures/Family/Masters/2015/January/Trip to
Whangarei/_MG_5465.CR2" as identical to item 11650
digikam.database: Scanning took 39 ms
digikam.database: Finishing took 0 ms

```
These files were on the NAS and are now on a local drive, so I think what it's
doing is matching them up in the cache?  Perhaps this will be a one time thing.

Will see when it finishes if it repeats itself.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 479711] Find new items at startup very slow (Mac)

2024-01-12 Thread bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=479711

--- Comment #2 from at...@electropositive.net ---
Thanks for the reply.  The unstable comment is not at all related to the
performance of the non scanning parts of digikam, just that to manage my media,
I need to know that the media is up to date, and to know that I have to wait
hours for a scan to finish.

I'm sure the logs will provide something useful.

I'm just going to check my sidecar (XMP) settings as I do have sidecar files,
perhaps even reset to default somehow, but even so I don't think that would
make it slow to over an hour right?

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 479711] Find new items at startup very slow (Mac)

2024-01-12 Thread Maik Qualmann
https://bugs.kde.org/show_bug.cgi?id=479711

Maik Qualmann  changed:

   What|Removed |Added

 CC||metzping...@gmail.com

--- Comment #1 from Maik Qualmann  ---
How a log is created under macOS is described here:

https://www.digikam.org/contribute/

Well, 90,000 images isn't that much. In a normal scan, we read the file date
information from all of these images. In a quick scan, only the file date
information of the albums (folders), so probably only 1-5 thousand date
information. If even that takes a long time, something must be very wrong. The
code for the scan function is actually already highly optimized, I don't see
any potential there anymore. There is of course the possibility that there is
poor interaction between Qt and macOS or something else. I'll add a debug this
weekend that will output the current number of files processed per second.

What also surprises me and I have read several times is that it is hardly
possible to work with digiKam during the scanning process. After all, the
scanning process runs in its own thread.
I just added a large external hard drive to my Windows test computer today with
initial scan. I was able to work with digiKam without any problems.

Maik

-- 
You are receiving this mail because:
You are watching all bug changes.