Discussion:
[digikam] [Bug 391840] New: Timeline does not show any pictures if range is too big
(too old to reply)
IWBR
2018-03-14 01:10:09 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=391840

Bug ID: 391840
Summary: Timeline does not show any pictures if range is too
big
Product: digikam
Version: 5.9.0
Platform: MS Windows
URL: https://imgur.com/a/cNsxR
OS: MS Windows
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: Searches-TimeLine
Assignee: digikam-bugs-***@kde.org
Reporter: ***@gmail.com
Target Milestone: ---

In the timeline panel, it is possible to select a range of dates, and all the
pictures within that range are displayed in the thumbnail view. However, if the
range is too wide, no picture is displayed. I guess it has to do with the
amount of pictures in the selection.

This is important since selecting the whole time range is the only possible way
to see and filter pictures from all collections at once.

I have attached a couple of screenshots, one showing that the range 2010-2018
works, but the range 2009-2018 doesn't. They can be seen here:
https://imgur.com/a/cNsxR
--
You are receiving this mail because:
You are watching all bug changes.
IWBR
2018-03-14 01:10:57 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=391840

IWBR <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com
--
You are receiving this mail because:
You are watching all bug changes.
Maik Qualmann
2018-03-14 05:58:36 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=391840

Maik Qualmann <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #1 from Maik Qualmann <***@gmail.com> ---
I can not reproduce the problem. I have selected an range from 2005-2018 and
the images are displayed. Depending on the number of displayed images, it may
take a while for the result to appear. But that's another problem when filling
the Icon view with such a large number of images and a bug report already
exists.

Maik
--
You are receiving this mail because:
You are watching all bug changes.
IWBR
2018-03-14 06:27:24 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=391840

--- Comment #2 from IWBR <***@gmail.com> ---
In this case, I can tell that it is not because digikam is still loading all
the items, since if that was the case, it would become a bit irresponsive for a
few seconds.

When selecting more than 60000 pictures, it just stops loading them. No
irresponsivenes or sluggishness, no high cpu usage, just an empty list. Maybe
the database query has some kind of limit on the number of elements it can
return?

I fired DebugView to see if I could see some useful message. This is what I saw
when it fails to load the items:
https://pastebin.com/bA3SguKW

Notice the 'Prepare failed!' and 'Failed to list url: " "'. These two messages
take less than a second to appear.

As a comparison, this is what it shows when a selection works properly:
https://pastebin.com/84hbhVsU
--
You are receiving this mail because:
You are watching all bug changes.
b***@kde.org
2018-03-14 08:37:05 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=391840

***@gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #3 from ***@gmail.com ---
Maik,

I remember an old limitation in imagelister mechanism, but is don't found again
it in source code. In my memory, I would said something around 1024 items...

IWBR,

To investigate more, it will be interesting to see the level of items when the
database do not return a response. So selecting the range of date to change the
expected amount of items returned will indicate when the database will not
respond to the query.

Gilles Caulier
--
You are receiving this mail because:
You are watching all bug changes.
b***@kde.org
2018-03-14 08:40:42 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=391840

--- Comment #4 from ***@gmail.com ---
MAik,

Look in
core/libs/database/items/imagelisterreceiver.cpp::ImageListerJobGrowingPartsSendingReceiver::receive().

What is that :

m_limit
m_maxLimit

???

Gilles
--
You are receiving this mail because:
You are watching all bug changes.
IWBR
2018-03-14 18:18:10 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=391840

--- Comment #5 from IWBR <***@gmail.com> ---
Gilles,

I am not sure if that is what you asked, but the database stopped responding at
some point between the selection of 68438 (works just fine) and 72600 elements
(empty response). That was the most I could narrow it down, since it's a very
slow process.
--
You are receiving this mail because:
You are watching all bug changes.
Maik Qualmann
2018-03-14 22:08:23 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=391840

--- Comment #6 from Maik Qualmann <***@gmail.com> ---
I'll take a look at it in the next few days. Was not there something with only
200 items in the block reading, so that the GUI does not freeze?

Maik
--
You are receiving this mail because:
You are watching all bug changes.
Maik Qualmann
2018-10-07 13:49:02 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=391840

--- Comment #7 from Maik Qualmann <***@gmail.com> ---
Git commit f27ab9c1051bd0a0bba6e79bc77899c74a7e6bf8 by Maik Qualmann.
Committed on 07/10/2018 at 13:47.
Pushed by mqualmann into branch 'master'.

add a global cache for grouped images
When we load the images into the Icon view,
we ask each time, whether there are grouped
images, with 30000 images in the view are that
also 30000 SQL query.
With this patch, the time to load a view with
many images is faster with MySQL 3x and with SQLite 2x.
Related: bug 398921, bug 396086, bug 397901

M +24 -0 core/libs/database/coredb/coredb.cpp
M +5 -0 core/libs/database/coredb/coredb.h
M +1 -10 core/libs/database/item/imageinfo.cpp
M +19 -2 core/libs/database/item/imageinfocache.cpp
M +7 -0 core/libs/database/item/imageinfocache.h
M +0 -3 core/libs/database/item/imageinfodata.h

https://commits.kde.org/digikam/f27ab9c1051bd0a0bba6e79bc77899c74a7e6bf8
--
You are receiving this mail because:
You are watching all bug changes.
Loading...