[Digikam-devel] unresponsive while scanning for new items
Simon Frei
freisim93 at gmail.com
Mon Jul 25 22:47:24 BST 2016
Yes that is not a problem. And the weird thing is it is not even writing
to it, but reading.
On 25/07/16 23:38, Gilles Caulier wrote:
> the thumb DB can growing up very quickly. Do you have enough free
> space on your device ?
>
> Gilles Caulier
>
> 2016-07-25 23:32 GMT+02:00 Simon Frei <freisim93 at gmail.com
> <mailto:freisim93 at gmail.com>>:
>
> I wanted to give you an additional piece of information: I just
> had the same issue again and could test what file is accessed:
> The unresponsivness (grey window) occurs while digikam is reading
> (sic!) from thumbnails-digikam.db.
>
>
> On 22/07/16 22:03, Gilles Caulier wrote:
>>
>>
>> 2016-07-22 21:19 GMT+02:00 Simon Frei <freisim93 at gmail.com
>> <mailto:freisim93 at gmail.com>>:
>>
>> Thanks for the information.
>> We discussed the issue of database location earlier already.
>> In the meantime I locate the database in ram, so access is
>> fast (digikam as a whole is a lot faster now). My issue is
>> not that digikam was slow, it is that it became completely.
>> unresponsive for no apparent reason (no performance limit).
>> For clarification (I have no knowledge of database
>> programming): Internal mysql uses the same "system" as sqlite
>> and the recent patches discussed were only concerning
>> external mysql?
>>
>>
>> yes there are. sqlite still unchanged.
>>
>> Mysql database is more designed to work with huge data, not
>> sqlite. This is why this kind of DB exists.
>> Don't forget the low level interface from Qt which is different
>> slightly different than sqlite.
>>
>> Gilles Caulier
>>
>> Trying mysql is on my list, but only after I reorganised my
>> collection. If sqlite really proves to be unusable with lots
>> of data, I may switch earlier.
>>
>>
>> On 22/07/16 19:38, Gilles Caulier wrote:
>>> The time latency from gui are done certainly by sqlite lock
>>> because a lots lots data need to be managed in database.
>>>
>>> Did you store the DB file in a fast device as a SSD. This
>>> improve also the performance until a limit of course.
>>>
>>> In all case, as you use git/master code, Mysql must give
>>> better results. We will interested to have a comparison.
>>>
>>> Gilles Caulier
>>>
>>> 2016-07-22 19:35 GMT+02:00 Gilles Caulier
>>> <caulier.gilles at gmail.com <mailto:caulier.gilles at gmail.com>>:
>>>
>>> From my experience sqlite use must be limited to 100Gb
>>> of images. For more, use Mysql. You can use internal
>>> server, no need a remote server. In this case, it will
>>> be used as sqlite.
>>>
>>> Gilles Caulier
>>>
>>> 2016-07-22 19:31 GMT+02:00 Simon Frei
>>> <freisim93 at gmail.com <mailto:freisim93 at gmail.com>>:
>>>
>>> Compiled from software-compilation. Git core is on
>>> commit c9f02e0.
>>>
>>>
>>> On 22/07/16 19:14, Gilles Caulier wrote:
>>>> Which digiKam version do you use ?
>>>>
>>>> Gilles Caulier
>>>>
>>>> 2016-07-22 17:32 GMT+02:00 Simon Frei
>>>> <freisim93 at gmail.com <mailto:freisim93 at gmail.com>>:
>>>>
>>>> Hi
>>>> I do not have enough detailed information to
>>>> file a bug and something similar might already
>>>> be reported. Still I wanted to inform you about
>>>> it. Maybe it helps in some way.
>>>> I just made changes to a big set of images
>>>> (350G) outside of digikam (metadata writing
>>>> with exiftool). So it took quite some time
>>>> searching for new items after startup
>>>> (notification on the bottom left), but never
>>>> used cpu or ram very hard. After some time
>>>> however digikam became unresponsive, just a
>>>> grey frame. The commandline did show that it
>>>> was still working in the background, the
>>>> following was displayed repeatedly:
>>>> digikam.dimg: "*somefile*" : JPEG file identified
>>>> digikam.metaengine: Orientation =>
>>>> Exif.Image.Orientation => 1
>>>> So digikam was still functioning, just not the
>>>> gui and still digikam did load the computer,
>>>> but not overload. After a certain time digikam
>>>> resurfaced and worked fine.
>>>> Cheers,
>>>> Simon
>>>> _______________________________________________
>>>> Digikam-devel mailing list
>>>> Digikam-devel at kde.org
>>>> <mailto:Digikam-devel at kde.org>
>>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Digikam-devel mailing list
>>>> Digikam-devel at kde.org <mailto:Digikam-devel at kde.org>
>>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>
>>>
>>> _______________________________________________
>>> Digikam-devel mailing list
>>> Digikam-devel at kde.org <mailto:Digikam-devel at kde.org>
>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Digikam-devel mailing list
>>> Digikam-devel at kde.org <mailto:Digikam-devel at kde.org>
>>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>
>>
>> _______________________________________________
>> Digikam-devel mailing list
>> Digikam-devel at kde.org <mailto:Digikam-devel at kde.org>
>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>
>>
>>
>>
>> _______________________________________________
>> Digikam-devel mailing list
>> Digikam-devel at kde.org <mailto:Digikam-devel at kde.org>
>> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org <mailto:Digikam-devel at kde.org>
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>
>
>
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20160725/153fa787/attachment.html>
More information about the Digikam-devel
mailing list