https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #22 from Maik Qualmann ---
There was actually a bug in connection with digiKam < 8.5.0 that only occurred
with the MySQL database, where images were scanned again.
With digiKam-8.5.0 there will therefore only be one larger scan, after which
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #21 from † ---
So, what this section from debug tells?
Digikam::DMetadata::load: Loading metadata with "Exiv2" backend from
"/FILEPATHNAMEREADSHERE"
Digikam::DImg::load: "/FILEPATHNAMEREADSHERE" : "RAW" file identified
Digikam::MetaEngine::
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #20 from † ---
I have let it run completely through earlier, but now I started interrupting
because it appeared so soon again. It went through last night though, taking
several hours. I'll check the settings, but I've made all transfers with
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #19 from Maik Qualmann ---
Could it simply be that your drive has not been fully scanned yet because you
keep interrupting it? A full scan of a USB drive with many GB of data can take
hours.
If you move or copy data, no scan is performed be
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #18 from † ---
Could this possibly be related to comparing data at sidecars and sql-database?
Is there any information what is exactly happening?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #17 from † ---
Still hanging after upgrading to 8.5.0 appimage.
So what is digikam trying to do? It is constantly starting thorough scanning of
files that has long been where they are (at USB drive). Scanning them isn't
directly related to
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #16 from _ ---
Was now at 25% which I interrupted. So currently I have to keep USB
disconnected when importing new files to make them appear. Process insists on
scanning all files when USB is connected and I don't know why.
--
You are rece
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #14 from _ ---
I was about to do similar plain transfer test, but it seems that digikam is
again stuck in scanning files at 19% while I have USB connected. There's
nothing new I have made between last connection.
--
You are receiving this
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #15 from _ ---
As such I have to keep the USB drive disconnected to get digikam properly scan
new files at local drive only. I haven't found reason why digikam does that
scan. All files at USB seem to be normally accessible.
--
You are rec
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #13 from _ ---
And those files in log were not transferred. It appears digikam started to scan
all files.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #12 from _ ---
No, 15 gb media was on local hdd which I moved to usb hdd within digikam. Such
time used is not usual.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #11 from Maik Qualmann ---
I understand correctly that you added 15GB of media? These need to be scanned
until their metadata is in the database, that will take a long time... There is
nothing unusual in the log, a normal file scan.
Maik
-
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #9 from _ ---
Debug output is just a sample from beginning and interrupted the process. It
seems that digikam is really scanning only this USB drive content slowly. When
I closed the program, then disconnected the drive, it didn't start the
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #10 from _ ---
Via Disks, SMART data is not available, but by checking filesystem is intact.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #8 from _ ---
Created attachment 175683
--> https://bugs.kde.org/attachment.cgi?id=175683&action=edit
debug output
all directory paths and such replaced from output to /*DIR*/ etc.
--
You are receiving this mail because:
You are watchin
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #7 from _ ---
I had it again. I'm running it now in debug mode but there's so much file paths
and such I possibly don't want to share and cleaning them would need work.
Anyway, what I did: i) Imported 100+ images from SD disk and renamed th
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #6 from _ ---
I have both local drive and external USB. This time it actually started when I
had USB connected which I don't always have. I'm unsure if the original slow
search process started after connecting the drive (and not when I actua
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #5 from Maik Qualmann ---
Where is your collection located (local drive, external USB drive or network)?
ow many albums and pictures does the collection contain?
How long does the scan take?
Maik
--
You are receiving this mail because:
Y
https://bugs.kde.org/show_bug.cgi?id=495437
Maik Qualmann changed:
What|Removed |Added
CC||metzping...@gmail.com
--- Comment #3 from Maik
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #4 from _ ---
I think I've had this occasionally with previous hardware too without disk
failures. I thought checking "fast scan" earlier totally fixed this.
Process just finished. If the problem persists I will try it again with
debugging
https://bugs.kde.org/show_bug.cgi?id=495437
caulier.gil...@gmail.com changed:
What|Removed |Added
Component|general |Database-Scan
CC|
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #2 from _ ---
Related processes in task manager seem to be
/usr/bin/perl -w /usr/bin/exiftool -stay_open true -@ - -common_args -charset
filename=UTF8 -charset iptc=UTF8
digikam
digikam seems to be occupying cpu constantly, exiftool hitti
https://bugs.kde.org/show_bug.cgi?id=495437
--- Comment #1 from _ ---
It appears that during the process files
thumbnails-digikam.db
thumbnails-digikam.db-journal
digikam4.db
digikam4.db-journal
are getting updated so also the thumbnail process seems to be going on after
all even though it's
23 matches
Mail list logo
