https://bugs.kde.org/show_bug.cgi?id=431951
Maik Qualmann changed:
What|Removed |Added
Resolution|--- |FIXED
Version Fixed In|
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #59 from griffiths_a...@icloud.com ---
Hi Maik,
I'm happy. I have experienced no lockup delays while giving it a thorough going
over... Seems that last change has really improved the performance due to
moving the long running op outside the
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #58 from griffiths_a...@icloud.com ---
Compiled, and checking now.
I had to apply the patch I mentioned in comment 54. I also see I should have
raised that as a separate report so I'll do so.
I'll report back later this evening with
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #57 from Maik Qualmann ---
Please test if the problem with the git/master version is fixed.
Maik
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #56 from Maik Qualmann ---
Git commit c7bda4772d7731404ff0337000dabcbff253102b by Maik Qualmann.
Committed on 19/02/2021 at 17:58.
Pushed by mqualmann into branch 'master'.
calculate QDateTime outside of the DB lock
Related: bug 432257
M
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #55 from griffiths_a...@icloud.com ---
Distinct improvement. I stashed and reapplied my local changes prior to
compile. (Inc the patch in prev comment).
Feb 18 21:41:34 digikam.coredb: getAllCreationDatesAndNumberOfImages() query
starts
Feb
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #54 from griffiths_a...@icloud.com ---
Checking now..
BTW, I had to apply this change a while ago to get a working compile. Seems
like a missing include.
diff --git a/core/tests/video/qtavcodecs.cpp b/core/tests/video/qtavcodecs.cpp
index
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #53 from Maik Qualmann ---
Update to current git/master and please try to find out where it takes a long
time in the item view when scrolling, or where it crashes after 10 seconds.
Maik
--
You are receiving this mail because:
You are
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #52 from Maik Qualmann ---
Git commit bec249c5dc8350b293c258fc767440139da3fcf0 by Maik Qualmann.
Committed on 18/02/2021 at 21:03.
Pushed by mqualmann into branch 'master'.
port QMap to a QHash
M +7-7
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #51 from Maik Qualmann ---
Ok, the problem was reported by KPhotoAlbum among others. Qt says it doesn't go
faster, many things have to be calculated when comparing dates, daylight saving
time, etc. Our problem is that we are using a QMap,
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #50 from griffiths_a...@icloud.com ---
Just did my own rough & ready mod to log query and post-processing in
core/libs/database/coredb/coredb.cpp:
QMap CoreDB::getAllCreationDatesAndNumberOfImages() const
{
qCDebug(DIGIKAM_COREDB_LOG)
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #49 from griffiths_a...@icloud.com ---
Thanks. I'll look forward to trying it.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #48 from Maik Qualmann ---
The fact is, if you had such times for queries everywhere in digiKam, digiKam
would be inoperable. So there must be something special about this query. There
is an indication in the web of a QDateTime problem in
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #47 from griffiths_a...@icloud.com ---
Maybe it's the post-processing in getAllCreationDatesAndNumberOfImages() to
return datesStatMap that is taking the time?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #46 from griffiths_a...@icloud.com ---
andyg@arch ~/Pictures/digikam % sqlite3 digikam4.db
SQLite version 3.34.1 2021-01-20 14:10:07
Enter ".help" for usage hints.
sqlite> .timer on
sqlite> .mode csv
sqlite> .output datequery.csv
sqlite>
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #45 from griffiths_a...@icloud.com ---
(In reply to Maik Qualmann from comment #43)
> On the other hand, you could install a DB Browser for SQLite, open the
> digikam4.db file in the DB Browser and execute the following query:
>
> SELECT
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #44 from griffiths_a...@icloud.com ---
Done, and it gets over that initial ASSERT crash.
But now it doesn't ASSERT crash where we want it to, as the timer is still <
2ms. So we need a way of not crashing where we expect the query to
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #43 from Maik Qualmann ---
On the other hand, you could install a DB Browser for SQLite, open the
digikam4.db file in the DB Browser and execute the following query:
SELECT creationDate FROM ImageInformation INNER JOIN Images ON
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #42 from Maik Qualmann ---
We Are Here:
https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/database/dbjobs/dbjob.cpp#L102
It is not normal for this query to take 10 seconds. maybe you could increase
the 1 times in the
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #41 from griffiths_a...@icloud.com ---
A second try. Crashes at the same place. Digikam::DatesJob::run()
[New Thread 0x7fff31ffb640 (LWP 1045062)]
digikam.coredb: CoreDbAccess lock time: 11949 ms
ASSERT: "d->timer.elapsed() < 1" in file
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #40 from griffiths_a...@icloud.com ---
Heh.. this was straight away during program startup. Not even displaying main
UI yet, just the splash.
digikam.general: Action Thread run 1 new jobs
[New Thread 0x7fff31ffb640 (LWP 1043703)]
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #39 from Maik Qualmann ---
Git commit f9a9d695c5a499291581a59dc1163b7c752a0ea1 by Maik Qualmann.
Committed on 18/02/2021 at 11:41.
Pushed by mqualmann into branch 'master'.
crash at 10 seconds lock time
M +2-0
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #38 from Maik Qualmann ---
Ok, almost 13 seconds for a database query is a problem. However, I suspect the
problem outside of digiKam. Let's see which query it concerns, we crash digikam
at 10 seconds.
Maik
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #37 from griffiths_a...@icloud.com ---
Thanks...
I've compiled from source as usual,
http://commits.kde.org/digikam/54974097ef336dc9ba1edaa90bbade42529ab084
Although I've run in GDB again I have not paused at the delay, as that affects
the
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #36 from caulier.gil...@gmail.com ---
Andy,
The new AppImage Linux bundle including last changes from Maik will be
available today late this evening at usual place:
https://files.kde.org/digikam/
Gilles Caulier
--
You are receiving this
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #35 from Maik Qualmann ---
Git commit c958341c0f442cf7bdc2e8adb35cc2f329bcd030 by Maik Qualmann.
Committed on 18/02/2021 at 07:13.
Pushed by mqualmann into branch 'master'.
restart timer after lock
M +2-2
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #34 from Maik Qualmann ---
A message is output if the lock time is longer than 10 ms. First of all, we
check whether a CoreDbAccess lock takes a long time.
Maik
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #33 from Maik Qualmann ---
Git commit 9bed4e982ab4b2f294e5e5f9e106d55baa08a6f6 by Maik Qualmann.
Committed on 18/02/2021 at 07:05.
Pushed by mqualmann into branch 'master'.
add test debug for CoreDbAccess lock time
M +10 -0
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #32 from Maik Qualmann ---
We are at the mutex where the item view wants to read the information for the
geo-icon in the thumbnail.
The mutex on which the thread is waiting has nothing to do with the
CoreDbAccess mutex. I'll add a debug
https://bugs.kde.org/show_bug.cgi?id=431951
griffiths_a...@icloud.com changed:
What|Removed |Added
Component|Database-Mysql |Database-Sqlite
--
You are
https://bugs.kde.org/show_bug.cgi?id=431951
griffiths_a...@icloud.com changed:
What|Removed |Added
Attachment #135103|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #30 from griffiths_a...@icloud.com ---
Agreed, the fundamental problem remains that it's having trouble for whatever
reason waiting to lock a mutex before doing some operation and this locks up
the whole UI. Logging the SQL was a roundabout
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #29 from Maik Qualmann ---
If you can scroll the view, i.e. the items became visible. A large part of the
database is already in the ItemInfo cache. So things like date, file size and
much more and are not reloaded from the database again.
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #28 from griffiths_a...@icloud.com ---
Hmm.. Have I just picked one of the very few places SQL is logged in that file?
Is it not performed generally? I picked
QMap CoreDB::getFormatStatistics(DatabaseItem::Category category)
const
but I
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #27 from griffiths_a...@icloud.com ---
To clarify.. I do see some digikam.database output when logging, just not the
SQL.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #26 from griffiths_a...@icloud.com ---
I'm trying to accumulate a bit more information on this issue for you.
Currently I'm running
https://invent.kde.org/graphics/digikam/commit/4c6b84b15cd6111aa9d3dfb430635a754f40ccba
directly compiled as
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #25 from griffiths_a...@icloud.com ---
Maik,
It still does it. In the latest backtrace, I Ctrl-C as soon as I feel its
locked up, and then 'bt' and leisurely read the output. Once I continue
execution it still hangs for a number of seconds
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #24 from griffiths_a...@icloud.com ---
Created attachment 135120
--> https://bugs.kde.org/attachment.cgi?id=135120=edit
Backtrace
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #23 from griffiths_a...@icloud.com ---
Thanks. Compiling now, I'll report back...
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #22 from Maik Qualmann ---
Git commit e9b438fdac100a7f0ea85f8078aec4080b47468a by Maik Qualmann.
Committed on 23/01/2021 at 21:51.
Pushed by mqualmann into branch 'master'.
use item count from the item model
SELECT COUNT() can be very slow
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #21 from griffiths_a...@icloud.com ---
I'm on SQLite now, as I mentioned above. Still experiencing the same issue
occasionally.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #20 from Maik Qualmann ---
Debug symbols are not necessary. I also know ao where the breakpoints are in
the code. I have no idea why you are having the problem with MySQL. The
CoreDbAccess() lock is wanted. The database is being accessed in
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #19 from griffiths_a...@icloud.com ---
I noticed that my binary was built without symbols, so I'm going to recompile
and retest.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #18 from griffiths_a...@icloud.com ---
Created attachment 135103
--> https://bugs.kde.org/attachment.cgi?id=135103=edit
Backtraces from digikam lockups
Backtraces as requested.
A range of actions were the cause: scrolling, selecting,
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #17 from griffiths_a...@icloud.com ---
I'm getting lockups again, so I'll start doing the backtraces. So far it looks
like Mutex locking in Digikam::CoreDbAccess::CoreDbAccess(), but I'll post
proper logs later.
--
You are receiving this
https://bugs.kde.org/show_bug.cgi?id=431951
caulier.gil...@gmail.com changed:
What|Removed |Added
Component|Thumbs-IconView |Database-Mysql
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #16 from griffiths_a...@icloud.com ---
Well, I can say with a small amount of confidence that I think my issue is
related to my MySQL db.
I have completed the MySQL to SQLite conversion overnight, and I'm now trying
it out in both my own
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #15 from caulier.gil...@gmail.com ---
To Maik, comment #12:
debug appimage version do not have an internal GDB inside. the "debug" argument
run the internal main executable with the GDB from the host system. See the
main internal bash
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #14 from griffiths_a...@icloud.com ---
The number of images varies with album. It could be 10 to 1000. I haven't
noticed any correlation between the number vs. the likelihood or duration of
the hang, but I'll look out for it.
Noted re.
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #13 from Maik Qualmann ---
Another question, does the number of images in the icon view make any
difference? How many images are we assuming in the view?
Maik
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #12 from Maik Qualmann ---
The AppImage isn't that well suited for this. You cannot run it in an external
GDB. You have to download the debug version of the AppImage and start it with
the debug option because it has an internal GDB.
Maik
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #11 from griffiths_a...@icloud.com ---
(In reply to griffiths_andy from comment #10)
> (In reply to Maik Qualmann from comment #9)
> > Yes, I'm in the right thread ((:-))
> > Problems with scrolling are not known and I cannot reproduce them
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #10 from griffiths_a...@icloud.com ---
(In reply to Maik Qualmann from comment #9)
> Yes, I'm in the right thread ((:-))
> Problems with scrolling are not known and I cannot reproduce them here with
> MySQL. Run digiKam in the GDB, stop it
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #9 from Maik Qualmann ---
Yes, I'm in the right thread ((:-))
Problems with scrolling are not known and I cannot reproduce them here with
MySQL. Run digiKam in the GDB, stop it if the problem occurs, copy the
backtrace and continue digiKam.
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #8 from griffiths_a...@icloud.com ---
(In reply to Maik Qualmann from comment #6)
> By the way, the text fields for title and description are the main problems.
> To get the status whether all have the same or different content, all must
>
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #7 from griffiths_a...@icloud.com ---
(In reply to Maik Qualmann from comment #5)
> The problem should only occur if the tags view in the right sidebar is open
> and many images are selected. In order to get the tag status (selected,
>
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #6 from Maik Qualmann ---
By the way, the text fields for title and description are the main problems. To
get the status whether all have the same or different content, all must be
read. If you have empty content here, it will take a
https://bugs.kde.org/show_bug.cgi?id=431951
Maik Qualmann changed:
What|Removed |Added
CC||metzping...@gmail.com
--- Comment #5 from Maik
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #4 from griffiths_a...@icloud.com ---
QT_LOGGING_RULES="digikam.*=true" QT_XCB_GL_INTEGRATION=none
Downloads/digiKam-7.2.0-rc-20210122T180600-x86-64.appimage
Still happens occasionally but the delay is much shorter, maybe only 2 or 3
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #3 from griffiths_a...@icloud.com ---
I'll try, but I always have issues running the appimage, and have to mess
around with eg.
QT_XCB_GL_INTEGRATION=none Downloads/digikam-7.2.0-beta1-x86-64.appimage
I only found that workaround after a
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #2 from caulier.gil...@gmail.com ---
Can you reproduce this problem with 7.2.0 RC AppImage bundle for linux ?
https://files.kde.org/digikam/
Gilles Caulier
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=431951
caulier.gil...@gmail.com changed:
What|Removed |Added
Component|general |Thumbs-IconView
CC|
https://bugs.kde.org/show_bug.cgi?id=431951
--- Comment #1 from griffiths_a...@icloud.com ---
Forgot to mention. The digikam process hits 100% CPU while this is happening.
The sub threads (QT processes, mysqld) appear to be unaffected.
--
You are receiving this mail because:
You are watching
63 matches
Mail list logo
