https://bugs.kde.org/show_bug.cgi?id=405235
caulier.gil...@gmail.com changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Version Fixed In|
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #56 from Mark Stoughton ---
Everything is fine on this end now. As far as I'm concerned this can be closed
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #55 from Mark Stoughton ---
I think I fixed it. Two different solutions, one for PC one for Mac. Both
versions seem to be running fine now.
For the PC
-Uninstall and reinstall Digikam.
For the Mac
- Uninstall and reinstall Digikam
-
https://bugs.kde.org/show_bug.cgi?id=405235
Mark Stoughton changed:
What|Removed |Added
OS|All |macOS
--- Comment #54 from Mark Stoughton
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #53 from Mark Stoughton ---
I've found one more thing. I swapped databases between the one that uses local
files and the one that uses files on the NAS.
The only difference was the location of the photo files. The databases were
both on
https://bugs.kde.org/show_bug.cgi?id=405235
Mark Stoughton changed:
What|Removed |Added
OS|Linux |All
--
You are receiving this mail because:
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #52 from Mark Stoughton ---
I ran a few more tests. I think that I've isolated the issue to occur only
when photos are stored on the NAS.
Test 1: Move the database off the System drive to a Thunderbolt Attached SSD -
Photos still on the
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #51 from Mark Stoughton ---
I ran a few more tests. I think that I've isolated the issue to occur only
when photos are stored on the NAS.
Test 1: Move the database off the System drive to a USB Attached SSD
-Startup time reduced to 21
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #50 from Maik Qualmann ---
If they change an album, there is no relevant access to the NAS/collection. All
information comes only from the database.
Maik
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #49 from Mark Stoughton ---
(In reply to Maik Qualmann from comment #48)
> If you change an album it's a pure database operation. It doesn't matter
> whether the album is on a NAS. As a test, I would move the digiKam databases
> to a
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #48 from Maik Qualmann ---
If you change an album it's a pure database operation. It doesn't matter
whether the album is on a NAS. As a test, I would move the digiKam databases to
a completely different directory.
Maik
--
You are
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #47 from Mark Stoughton ---
Hi,
That is correct, it takes about 3 minutes to change folders while using the
program. While in a single folder the program works fine, but takes about a
minute to read the metadata, particularly the EXIF
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #46 from Mark Stoughton ---
I checked the rights and digicam does have RW on the entire drive. The only
thing that I can think of is that there may be some issue because the files are
on a NAS. So this morning I installed it on another
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #45 from Mark Stoughton ---
(In reply to Maik Qualmann from comment #44)
> I understand you correctly that the change from an album takes 3 minutes
> after the start?
> This is a database operation, in principle there is no loss of time.
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #44 from Maik Qualmann ---
I understand you correctly that the change from an album takes 3 minutes after
the start?
This is a database operation, in principle there is no loss of time. You must
have very, very slow access to your database.
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #43 from Mark Stoughton ---
This is a run with the boxes unchecked. Load time was down to 30 minutes
exactly
Last login: Thu Feb 10 12:53:11 on ttys000
markstoughton@Marks-Mac-mini ~ % export QT_LOGGING_RULES="digikam*=true"
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #42 from Mark Stoughton ---
I unchecked the Settings-Collections I unchecked the box that says "Monitor the
ablbums for external changes(requires restart). Is that the right one? If
not, please direct me to the right one. Thanks.
P.S.
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #41 from Maik Qualmann ---
I don't think you have the right option unchecked. It was enabled anyway and
adding every album to QFilesSystemWatcher is known to cause extreme startup
times on MacOS. If the option is deactivated, digiKam must
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #40 from caulier.gil...@gmail.com ---
oups, sorry wrong bugzilla entry. Ignore my last comment.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #39 from caulier.gil...@gmail.com ---
I use a macbook pro here, with last big sur, and i never seen this dyfunction
here.
I tried sqlite or mysql internal database, and all work as expected. Of course
my disk is a NVME SSD.
Image are also
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #38 from Mark Stoughton ---
After some use, the album switching got down to. fairly repeatable three
minutes, regardless of the number of photos in the album
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #37 from Mark Stoughton ---
I deactivated the monitor external changes and restarted. I saw no difference
in either startup time (40 minutes) or album switching (15 minutes).
--
You are receiving this mail because:
You are watching all
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #36 from Mark Stoughton ---
It was activated. I'll try again after deactivating it
(In reply to Maik Qualmann from comment #34)
> I assume you have activated the option to monitor for external changes in
> the digiKam settings under
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #35 from Mark Stoughton ---
I ran the debug session. I've annotated it because digicam stopped for several
minutes in different places along the way, and the log does not show the
pauses.
It took 41 minutes from start to finish
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #34 from Maik Qualmann ---
I assume you have activated the option to monitor for external changes in the
digiKam settings under Collection. This option must be deactivated under MacOS,
as it causes the albums to load extremely slowly.
Maik
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #33 from Mark Stoughton ---
sorry for the slow reply. It's 10 minutes after the smash screen disappears.
The app shows up as non-responsive in Task manager in Windows or in Force Quit
on the Mac.
--
You are receiving this mail because:
this issue.
From: MarcP
Sent: Saturday, January 22, 2022 1:23 PM
To: geoph...@hotmail.com
Subject: [digikam] [Bug 405235] Slow startup and new file scan on low latency
networks
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #31 from MarcP ---
Hi Mark, you mean 10-minutes since the digi
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #31 from MarcP ---
Hi Mark, you mean 10-minutes since the digikam splash disappears and the
interface shows up, or until the progress bar reaches 100%? Are the pictures
in your library already imported or it's the first scan?
I'm now in a
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #30 from Maik Qualmann ---
Create a start log, under Windows with the program DebugView from Microsoft,
under Mac in the terminal, each with an active Qt-Debug environment variable.
The procedure is described here:
https://bugs.kde.org/show_bug.cgi?id=405235
Mark Stoughton changed:
What|Removed |Added
Version|7.4.0 |7.5.0
CC|
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #28 from Maik Qualmann ---
Git commit 6545c2e25eb5f5104d2069f34ccc8b2d5d094273 by Maik Qualmann.
Committed on 06/09/2021 at 17:50.
Pushed by mqualmann into branch 'master'.
added fast scan as an option in the settings
M +2-1
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #27 from Maik Qualmann ---
Hmm, yes I can reproduce, e.g. change an image with Gimp. For programs that do
not create temporary files to change the image, the album modification date
remains the same.
Let's see, either the quick scan is
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #26 from MarcP ---
Hi Maik.
Just one note. Yesterday I added a bunch of tags to the pictures of an album
using Digikam 7.3 in another computer.
Today when I started the flatpak preview of flatpak 7.4, it did not detect
these changes, so
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #25 from Maik Qualmann ---
But it must also be said that having to read all of the metadata will not speed
up the first scan of a collection. For this I would recommend a NAS that can
also be connected via USB. It is now very easy to switch
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #24 from caulier.gil...@gmail.com ---
I agree, Maik has done a wonderful optimization in source code.
Congratulations...
Gilles
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #23 from MarcP ---
After trying thursday's build (Rev.: 61cee1cc9536b88b073acce47d37dc85bb1bbfdd),
the initial scan was further reduced to 2 minutes and 29 seconds. That's only
17% of the time it took two weeks ago (14m20s), so more than 5
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #22 from Maik Qualmann ---
Git commit 9a443ffcae0f417d355a16e5040225f3a8e7075a by Maik Qualmann.
Committed on 18/08/2021 at 17:33.
Pushed by mqualmann into branch 'master'.
use album date cache to reduce file reading
Related: bug 437771,
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #21 from Maik Qualmann ---
In the first section we look for possible deleted albums or whether digiKam
albums have just been moved. That means we read the database and look directly
in the collection to see whether the folder still exists,
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #20 from MarcP ---
By the way, when the initial scan starts, it stays for a while at 0%, before
the progress bar starts to move towards the 100%.
I must measured it,
from 0% to 1%: 2m26s
>From 1% to 100%: 2m16s
That's about half of the
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #19 from MarcP ---
Hi again,
I could not find to run digikam in debug mode using the flatpak version, but I
measured the date when I launched it and when it finished the initial scan.
After upgrading to today's version (with no new
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #18 from Maik Qualmann ---
By the way, digiKam print the scan time in the terminal with active debug
variable.
digikam.database: Complete scan took: 22110 msecs.
Maik
--
You are receiving this mail because:
You are watching all bug
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #17 from MarcP ---
Ok! I'll run some tests this week and get back to you.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #16 from Maik Qualmann ---
Hi Marc,
Feedback welcome again. The first scan with this patch will not change the scan
time, as the database must first be filled with the albums modification date.
The next digiKam starts will be interesting.
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #15 from Maik Qualmann ---
Git commit d14487fc0da4e26bc7ba2a82730b7a36d1c4cff6 by Maik Qualmann.
Committed on 16/08/2021 at 20:09.
Pushed by mqualmann into branch 'master'.
use album modification date to speed up the initial scan
Database
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #14 from Maik Qualmann ---
This means that the percentage display in the status bar, depending on whether
images have been removed or added, e.g. jumps from 90% to 100% or lingers on
100% for a while before it is finished. If you have a
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #13 from MarcP ---
Today I updated the flatpak version (v.:
03f233383d94c20099afe07e75edb727694e5c3c) and tried again:
Same library, same network, no new items: 7 minutes and 37 seconds.
That's about half the time it took yesterday! Good
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #12 from MarcP ---
Ok, so, as a reference, version 7.4.0 rev
90854f4a4e9e06ed2f1196afbee0b92fe5bf9fe8 took 14 minutes and 20 seconds since
it was started until it finished checking for changes (there were none since I
already started it a
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #11 from MarcP ---
I'll test with my collections these days and provide some feedback as well.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #10 from Maik Qualmann ---
As a test environment, I use my Fritz-Box router with a connected 2.5 inch WD
hard drive via USB with 100Mb/s LAN network. Mounted via Cifs-SMB. So not
really a fast NAS. There are about 30,000 images on the hard
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #9 from Maik Qualmann ---
Git commit 03f233383d94c20099afe07e75edb727694e5c3c by Maik Qualmann.
Committed on 09/08/2021 at 19:29.
Pushed by mqualmann into branch 'master'.
first step for a faster scan of network drives
We only run through
https://bugs.kde.org/show_bug.cgi?id=405235
caulier.gil...@gmail.com changed:
What|Removed |Added
Version|6.0.0 |7.4.0
--
You are receiving this
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #8 from MarcP ---
I believe nothing has changed on this regards. The total startup time still
heavily depends on the latency of the medium where pictures are stored.
--
You are receiving this mail because:
You are watching all bug
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #7 from caulier.gil...@gmail.com ---
With next digiKam 7.4.0 release, AppImage bundle is compiled using a more
recent Linux Mageia 7.1 host. Last stable Qt 5.15.2 and KF5 5.84 are used.
ImageMagick codec 7 and libav 58 (ffmpeg) are used to
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #6 from MarcP ---
Ok, so I experienced this problem when I lived abroad, and had a ~100ms ping,
but it's no longer the case, so I tried to find ways to assess startup and
scanning speed by simulating high network latencies.
So I used this
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #5 from caulier.gil...@gmail.com ---
https://bugs.kde.org/show_bug.cgi?id=417121
--- Comment #3 from caulier.gil...@gmail.com ---
digiKam 7.0.0 stable release is now published:
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #4 from IWBR ---
I see. Don't worry about it. It's mostly a network problem. However, as I
mentioned, due to the high latency, Digikam thinks the path is not available,
although I can browse to that location using Ubuntu's file manager.
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #3 from Maik Qualmann ---
Another thing is the latency of over 100 ms (10 times an internet connection).
Assuming that the query on whether a file exists would take so long, and
probably longer, 100,000 files would take over 2.7 hours!
https://bugs.kde.org/show_bug.cgi?id=405235
Maik Qualmann changed:
What|Removed |Added
CC||metzping...@gmail.com
--- Comment #2 from Maik
https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #1 from IWBR ---
Just a heads up. Even when the main interface has shown up and new file scan is
disabled, the interface freezes intermittently. In the console, I see messages
like these every time it happens:
https://bugs.kde.org/show_bug.cgi?id=405235
caulier.gil...@gmail.com changed:
What|Removed |Added
Component|Database|Database-Scan
CC|
https://bugs.kde.org/show_bug.cgi?id=405235
IWBR changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
61 matches
Mail list logo
