SUMMARY I have a +300K database using MySQL internal store. From beginning, the "Search" tab (left side) begin to search in database without user typing nothing. Even with the "Automatically begin search" option enable, search should start at least when user begin to type some character and not start just when user open the "Search" tab. STEPS TO REPRODUCE 1. Click on "Search" tab on the left side of Digikam OBSERVED RESULT Digikam shows images even with "Automatically begin search" disabled. EXPECTED RESULT Show nothing at all (do no search) till user type some character on search field.
The last saved search is executed. You see a list of saved searches, where the first list entry is executed. Store a quick search, use a name so that it is at the top position. The idea here is actually that the user in the Iconview is not facing an empty view. Maik
I have two distinct PCs with Digikam. In both, I have no saved searches. In fact, there is only the "Actual search" item in the list and even if I "Edit" that item (nothing happens), nothing changes. Any time I click in "Search" tab, appears a lot of images with not knew filters. Even if I click in "Advanced search", then button "Reset" and finally button "Accept", the same. And moreover, as I wrote, I have disabled "Auto begin ..." so even in the case a supposed search was saved, Digikam should not search nothing till I press "Enter".
Just tested here, the "Actual search" in the list is executed. It is always the "last" search that would be performed. The sidebar concept always provides for the last view to be restored, the last tags, the last date, the last labels, the last selected album. Maik
The problem is not the search in the DB, this takes only a fraction of a second, even with many items. The problem is, if your search wants to show a lot of items, this is still much faster with SQLite than MySQL. If your "last" search has yielded only a few items, the call is not disturbing either. As I said, we are working on the speed of MySQL. But I really do not want to see a dead thumbnail view and right sidebar, when calling up the search tab. Maik
(In reply to Maik Qualmann from comment #3) > Just tested here, the "Actual search" in the list is executed. It is always > the "last" search that would be performed. The sidebar concept always > provides for the last view to be restored, the last tags, the last date, the > last labels, the last selected album. > > Maik Maybe I need to share with you a video recording of the steps, to show you that I have NO fields of any kind with any value, so the result should be no show any thumbnail!! The speed in searching is a secondary issue if the search (as it should work with my configuration) doesn't start till I press "Enter" key. Tomorrow I'll share with you the screen recording.
I notice that you keep talking about your blank search field. Yes, there is nothing in it. You understood that you do not have to enter complex searches over and over again? These can be saved. These appear in the list where the "Actual search" is located. Here you can repeat the search with just one click. The "Actual search" is just your last search which is automatically saved, this entry is started when the search tab is called up. Of course it can also be that something is wrong with your DB table in which the searches are stored. Then the output in the console would be interesting. Maik
(In reply to Maik Qualmann from comment #6) > I notice that you keep talking about your blank search field. Yes, there is > nothing in it. You understood that you do not have to enter complex searches > over and over again? These can be saved. These appear in the list where the > "Actual search" is located. Here you can repeat the search with just one > click. Yes Mike, I insist in talk about the search function must be changed to be useful and usable. This time, to avoid any "change" in configuration that could interfere in the results, I deleted all database files of DK and create them again. The only change was add "SVG" to mimetypes. Scenario: Digikam 6.2 with SQLite database just after reescaning 28k images. In the video https://fromsmash.com/YC56l.yvIC-c0 you can see each time I DELETE the field to search and I press "Enter" key to force to search nothing, when I click the "Search" tab again, it appears. I didn't save anything, so this is just the first problem: User should be free to save the searches he considers usual and if user deletes any string in the search field ... why do not save this "empty" field too automatically? It's such incoherent, I think. In the video, I even enter in "Advanced search" to reset ("Reset" button) the filter criteria but the result is even worst: Digikam will show ALL thumbnails (and takes a loooong time), when I'm not giving any criteria to search and even have disabled "Automatically begin search". I expect this time I explained clearly the problems related with the search tab. ;)
Please, forgot that video. The conversion to make it smaller dropped a lot of frames and makes the result a nonsense. Tomorrow I'll send it as it should be uploaded. I'm sorry
Ok, that explains it. I had looked at the video 3 times and could not do anything with it. Regardless of the video, yes if you confirm a reset advanced search with OK, all items are found - because the SQL query gives it. Otherwise, with 28K images and SQLite no search and display of items take no longer than 2 seconds. Maik
This is the video with comments https://fromsmash.com/q6VU0vcQW3-c0 As I wrote even is users-list, the search tab becomes unusable and his way of work is not intuitive, so if user have thousand of images, is desperate to try to search something. This is what I propose: - By default, "Auto begin search" should no be enabled. It's usual in many cases that user must search for a foreign name and fails while typing the name while reading the name in other place, so Digikam begins to search an incomplete field, complicating more the search process than finish with a freezed Digikam interface. - Do not autosave last search. User should be who interactively save searches he does giving them a name. It's a madness that each time user access to search tab, the last NOT saved search begins. It should be void each time user click on "Search" tab. I'm not considering in this proposal any performance related issue, but the fact is that is something to take into account too (the video was over a 28k images database, not over the +300k photos I usually use). This way, if I want to search, I'll click in "Search", no thumbnails should be showed, then I'll type the word(s) I want to search and finally I press "Enter" key. Then, and only then, the thumbnails of the images that matches should be showed. That's my opinion as user. Thank you
Do not get me wrong. The concept is also that the search is a virtual album and the last view is restored. You also do not expect that you have to press on album, tags or date tab first on Enter. The last view is restored. What we need to change is to speed up the search as much as possible. But above all, the GUI must not freeze and a new input must possible and be executed immediately. We have to change that. Maik
(In reply to Maik Qualmann from comment #11) > Do not get me wrong. The concept is also that the search is a virtual album > and the last view is restored. You also do not expect that you have to press > on album, tags or date tab first on Enter. The last view is restored. What > we need to change is to speed up the search as much as possible. But above > all, the GUI must not freeze and a new input must possible and be executed > immediately. We have to change that. > > Maik Don't worry, I know you always try to do the best for Digikam. I understand the concept of virtual album based on saves search, but when we work with thousand images with metadata, user ends hating the unresponsiveness of interface each time he did a long search autosaved in the last use of the search tab. I could understand that any previous saved search appeared as a virtual album (next to the real albums tree) when the user intentionally save it. But is not the case. The auto-beginning of search, IMHO, is more focused to the searches that interactively shows words matching the letters user is typing (like when you use the "Search using ..." field that all we know in any web browser and the browser shows a dropdown list of possible matches). But just nowadays, using DK 6.2 over SQL Lite, retrieving all thumbnails related to a "incomplete keyword" (while user is typing) has undesirable performance consequences. Even (why not?) to show (like mentioned web browsers dropdown lists) the possible matches without showing thumbnails, will improve drastically the search experience. ;)
But you know that you can disable the automatic search when typing text? Right mouse button menu in the input field. Maik
(In reply to Maik Qualmann from comment #13) > But you know that you can disable the automatic search when typing text? > Right mouse button menu in the input field. > > Maik Yes, I know that fact as I commented in https://bugs.kde.org/show_bug.cgi?id=411099#c10 and in the video. Some time ago I suggested to change that option for a more intuitive (visible without "Right clicking") way to enable/disable that option. But the fact (visible in the video) it that even with "Auto begin ..." disabled, if user click on "Search tab" the last search (not manually saved) begins and doesn't matter if user delete the word(s) that he wrote in last search, cause DK will not autosave an "empty" search ... As maybe I didn't explain clearly, I resume: The "autosaving last search" in "Search" tab should be disabled or (as the "Auto begin ...") DK should let user decide if he wants that feature enabled. Thank you anyway, it was only a suggestion from an user with large databases who suffer the effects of the actual way the search feature is working ;)
*** Bug 411298 has been marked as a duplicate of this bug. ***
*** Bug 425980 has been marked as a duplicate of this bug. ***
*** Bug 447072 has been marked as a duplicate of this bug. ***
Hi Maik! I full agree with Rafael Linux User! Yesterday, one search term returned 160,000 results. I closed the digikam, because I finished the work. I opened digikam today and I wanted to search for a word, but the digikam was busy compiling yesterday’s search for long minutes. I waited, I waited and at the end of the operation (about 3 minutes) I could see the results of yesterday’s search. Wonderful... ...but no longer current! If the user wants to search, then the user is not interested in the results of the previous search (if so, use the saved search). This operation of search is very frustrating at times! Why can't the user disable/enable the last search function? Please, please change that!
Peter, unfortunately, I understand that if nothing has been done about it in the searches since 2019 to date, then they don't see it as an issue. Most likely because they don't work with hundreds of thousands of photos on a daily basis. Moreover, to date, I know users who, in order to avoid this problem, prefer to use the o.s. file manager search and thus avoid the waiting time that occurs because of what I have already mentioned in my previous messages. Regards
On Sat, 26 Feb 2022 22:53:15 +0000 "Rafael Linux User" <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=411099 > > --- Comment #19 from Rafael Linux User > Most likely because they don't work with hundreds of thousands of > photos on a daily basis. I don't have hundredS of thousands but I deal in tenS of thousands. I also am not enthusiastic about the "re-search' My solution is much more low-tech and is user dependent. When I'm done with my search, I press the reset button.
(In reply to Syv from comment #20) > On Sat, 26 Feb 2022 22:53:15 +0000 > "Rafael Linux User" <bugzilla_noreply@kde.org> wrote: > > > https://bugs.kde.org/show_bug.cgi?id=411099 > > > > --- Comment #19 from Rafael Linux User > > Most likely because they don't work with hundreds of thousands of > > photos on a daily basis. > > I don't have hundredS of thousands but I deal in tenS of thousands. I > also am not enthusiastic about the "re-search' > > My solution is much more low-tech and is user dependent. > > When I'm done with my search, I press the reset button. Indeed, as you do not have hundreds of thousands, you are unaware that while the automatic search is being performed by clicking on "Search", the interface is often blocked and allows you to click on "Reset". Fortunately for you, you will not have this problem.
On Sun, 27 Feb 2022 01:23:19 +0000 "Rafael Linux User" <bugzilla_noreply@kde.org> wrote: > > My solution is much more low-tech and is user dependent. > > > > When I'm done with my search, I press the reset button. > > Indeed, as you do not have hundreds of thousands, you are unaware > that while the automatic search is being performed by clicking on > "Search", the interface is often blocked and allows you to click on > "Reset". Fortunately for you, you will not have this problem. You didn't read it carefully. I press the reset AFTER my successful search, while I'm still in the search panel
> You didn't read it carefully. I press the reset AFTER my successful > search, while I'm still in the search panel Unfortunately, this method does not solve the problems... :-( ...however, it creates another problem: after clicking the reset and ok button, in the search field of search panel the text is does not receive the "reset" value, and my digikam starts looking for something again, but I can't know what: Result is not relevant with the value of the search field. :-(
Syv, you will never have this issue. My photos are on an NFS network drive and that complicates the management by Digikam even more, it's normal. What I insist is not normal, is that if I press "reset" after a search, even without having "Start automatic search" activated, Digikam simply stops reacting, freezing parts of its windows for 1 to 4 minutes. After that time, if (while in the search tab) I resize the Digikam window itself, the rendering of the Digikam window is not done properly and it does NOT let me interact with Digikam until it "comes back to itself". If I monitor the system status (CPU %, hard disk access and network access), there are two Digikam processes consuming 12-15% CPU each (that's nothing). If I resize the Digikam window from any other tab than the search tab, everything is fine. So, "resetting" is useless, whether I do it "before" or "after", it doesn't matter. The fact is that, being in the search window, with NO parameters in any input box, the search process of EVERYTHING seems to restart every time the window is resized, leaving Digikam "frozen" for 1 to 3 minutes.
That sounds strange and I can't reproduce it here. If the size of the window changes, no new search process is started. With how many items in the view can the problem be reproduced and where is the database (MySQL/SQLite) located? Maik
(In reply to Maik Qualmann from comment #25) > That sounds strange and I can't reproduce it here. If the size of the window > changes, no new search process is started. With how many items in the view > can the problem be reproduced and where is the database (MySQL/SQLite) > located? > > Maik https://fromsmash.com/Digikam-hangs-on-searching Using SQLLite in a local database stored in a SSD. If I leave search tab selected, close Digikam and launch it again , it stays several minutes showing the splash window, cause Digikam is opened with search tab selected (last one I used before I closed digikam).
(In reply to Maik Qualmann from comment #11) > Do not get me wrong. The concept is also that the search is a virtual album > and the last view is restored. You also do not expect that you have to press > on album, tags or date tab first on Enter. The last view is restored. What > we need to change is to speed up the search as much as possible. But above > all, the GUI must not freeze and a new input must possible and be executed > immediately. We have to change that. > > Maik Hi Maik. I tried again... "...last view is restored." In this case, the name of the window is misleading: "New search". Name of the window name is "New", the displayed results are old. I tried to accept the explanation: "The idea here is actually that the user in the Iconview is not facing an empty view", but I don't understand why the empty window is a problem... ...if the user wants to search, he does not expect to receive results before starting the search. Only an idea, that's all that's needed: https://mega.nz/folder/dYoGTZiI#d3L7YiCgSrYZstokzyFMaQ
In the proposed case the previous search text can remain in the search box (as it works now), but digiKam do not start the search until the user presses enter or continues to fill in the text.
Maik please! Add at least one "Stop Search" button. Currently, there is a small trick (born of necessity) that can be used to interrupt the long and pointless search, but a stop search button would be more elegant.
I admit I don't understand where the problem is. I use the search often, I don't have a speed problem, even if the result contains several 10 thousand images, it is built up in current digiKam versions in 1-2 seconds. I see in Comment 27 that you don't seem to understand the "New search" button. "New search" opens a window in which all search options are reset. If you mean the quick search at the top position, here you can disable the automatic start of the search when typing with the right mouse button menu. Maik
(In reply to Maik Qualmann from comment #30) > I admit I don't understand where the problem is. I use the search often, I > don't have a speed problem, even if the result contains several 10 thousand > images, it is built up in current digiKam versions in 1-2 seconds. I see in > Comment 27 that you don't seem to understand the "New search" button. "New > search" opens a window in which all search options are reset. If you mean > the quick search at the top position, here you can disable the automatic > start of the search when typing with the right mouse button menu. > > Maik I will make a video about the problem soon... "10 thousand > images" I have 200 000 "> the quick search at the top position, here you can disable the automatic > start of the search when typing with the right mouse button menu." It was the first i turned off a long time ago. "you don't seem to understand the "New search" button" digiKam becomes completely unusable until the search is complete. when the user clicks on the search tab digikam repeats the previous search. if the result is hundreds of thousands of hits, digikam will not allow another search until the previous one is finished. not even with the new search button! this is the problem!
digiKam long search (6 minutes): https://mega.nz/folder/dYoGTZiI#d3L7YiCgSrYZstokzyFMaQ In this video: -- previous search is the anything containing the word jpg (190.000 hit. This is good in case i need it, but you don't have to anymore, I need the "ablak". The search could not be interrupted.) -- this is no longer necessary, what i want to search: "ablak" (window) -- the search took nearly six minutes, due to the search for the previous irrelevant jpg word
(In reply to Peter from comment #32) > digiKam long search (6 minutes): > https://mega.nz/folder/dYoGTZiI#d3L7YiCgSrYZstokzyFMaQ > > In this video: > -- previous search is the anything containing the word jpg (190.000 hit. > This is good in case i need it, but you don't have to anymore, I need the > "ablak". The search could not be interrupted.) > -- this is no longer necessary, what i want to search: "ablak" (window) > -- the search took nearly six minutes, due to the search for the previous > irrelevant jpg word I just related same issues (video is deleted yet) and despite search speed is much better from version 6, IMHO "Quick search" (no "New search" cause I don't need to reuse them) should not begin to search automatically while typing and the way to disable it is not easy to find, is not intuitive.
@Raphael digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
Hi Maik. * Before starting the search, digiKam shows irrelevant results * The search cannot be stopped! In the case of 200,000 photos, the search takes several minutes, until digikam finishes the search, it does not respond to starting a new search! * The search starts immediately when the user clicks on the search tab, although the results are usually already irrelevant. * The user must use a trick to circumvent this action. Yes, this is still valid problem (in 8.1.0 too).
(In reply to Peter from comment #35) > Hi Maik. > * Before starting the search, digiKam shows irrelevant results > * The search cannot be stopped! In the case of 200,000 photos, the search > takes several minutes, until digikam finishes the search, it does not > respond to starting a new search! > * The search starts immediately when the user clicks on the search tab, > although the results are usually already irrelevant. > * The user must use a trick to circumvent this action. > > Yes, this is still valid problem (in 8.1.0 too). Yes, still same issue.
Hi all, The digiKam 8.4.0 Appimage bundle pre-release is now based on last modern frameworks Qt 6.7.0 and KDE 6.2.0. File can be downloaded at usual place : https://files.kde.org/digikam/ Take a care : the bundle is named with the suffix "-Qt6" not "-Qt5". This bundle is compiled under Ubuntu 22.04 and require a Linux with GlibC version >= 2.35 to run. Can you reproduce the dysfonction with this version? Thanks in advance Gilles Caulier
(In reply to caulier.gilles from comment #37) > Hi all, > > The digiKam 8.4.0 Appimage bundle pre-release is now based on last modern > frameworks Qt 6.7.0 and KDE 6.2.0. > > File can be downloaded at usual place : https://files.kde.org/digikam/ > Take a care : the bundle is named with the suffix "-Qt6" not "-Qt5". This > bundle is compiled under Ubuntu 22.04 and require a Linux with GlibC version > >= 2.35 to run. > > Can you reproduce the dysfonction with this version? > > Thanks in advance > > Gilles Caulier Yes, this is still valid problem.