0.84: Search progress and results window
Moderators: XnTriq, helmut, xnview, Dreamer
0.84: Search progress and results window
XnView: MP 0.84
OS: Windows 7 - 64bit
There are a number of bugs and minor problems related to the window that pops up when a search is started.
Some of these have been reported before, often as components of bigger problems, so I thought I'd summarise them all here, along with some new issues.
Issue 1:
searching recursively using the catalog: the current pathname stays forever on "DB". For slow searches like XMP content this can potentially result in minutes passing with no indication of anything happening.
Posted in http://newsgroup.xnview.com/viewtopic.php?p=139848
Issue 2:
Same situation as issue 1: the "DB" text is apparently always written in black, so with the dark theme selected no text is visible. When catalog is not used then the pathnames are always written in a contrasting colour text.
Posted in http://newsgroup.xnview.com/viewtopic.php?p=139848
Issue 3:
When more than a small number of files match then the "finished..." text is off the bottom of the window - the user has no indication that the search has finished unless they manually scroll to the bottom of the list to check. There should be an indication of completion in the top area - for example: "Finished : nn files found"
Posted in http://newsgroup.xnview.com/viewtopic.php?p=139850
Issue 4:
When a search is active then there are two buttons: "Abort" and "Cancel". They seem to do the same thing.
Posted in: http://newsgroup.xnview.com/viewtopic.php?p=139851
Issue 5:
"Abort" and "Cancel" buttons do nothing useful if a catalogue search is underway. For example a search for an XMP field value may normally run for 10 minutes. Pressing abort or cancel after the search has started will cause the program to become non-responsive until the time to carry out the full search has passed.
A non-catalogue search returns in a reasonably short time.
Posted in: http://newsgroup.xnview.com/viewtopic.php?p=139853
OS: Windows 7 - 64bit
There are a number of bugs and minor problems related to the window that pops up when a search is started.
Some of these have been reported before, often as components of bigger problems, so I thought I'd summarise them all here, along with some new issues.
Issue 1:
searching recursively using the catalog: the current pathname stays forever on "DB". For slow searches like XMP content this can potentially result in minutes passing with no indication of anything happening.
Posted in http://newsgroup.xnview.com/viewtopic.php?p=139848
Issue 2:
Same situation as issue 1: the "DB" text is apparently always written in black, so with the dark theme selected no text is visible. When catalog is not used then the pathnames are always written in a contrasting colour text.
Posted in http://newsgroup.xnview.com/viewtopic.php?p=139848
Issue 3:
When more than a small number of files match then the "finished..." text is off the bottom of the window - the user has no indication that the search has finished unless they manually scroll to the bottom of the list to check. There should be an indication of completion in the top area - for example: "Finished : nn files found"
Posted in http://newsgroup.xnview.com/viewtopic.php?p=139850
Issue 4:
When a search is active then there are two buttons: "Abort" and "Cancel". They seem to do the same thing.
Posted in: http://newsgroup.xnview.com/viewtopic.php?p=139851
Issue 5:
"Abort" and "Cancel" buttons do nothing useful if a catalogue search is underway. For example a search for an XMP field value may normally run for 10 minutes. Pressing abort or cancel after the search has started will cause the program to become non-responsive until the time to carry out the full search has passed.
A non-catalogue search returns in a reasonably short time.
Posted in: http://newsgroup.xnview.com/viewtopic.php?p=139853
Last edited by CameronD on Sun Mar 12, 2017 7:22 am, edited 1 time in total.
Re: 0.84: Search progress and results window
CameronD, thank you very much for your reporting these issues with "Search". Could you please post one bug report per issue? (I know, this is some extra work but it will make handling your issues much easier.)
Re: 0.84: Search progress and results window
I will split them up eventually, although I suspect 1 and 5 might be strongly linked - but the others are certainly discrete problems.
Re: 0.84: Search progress and results window
Again, thank you for summarizing the issues related to search, CameronD. Often, summarizing things makes bug handling difficult. Let's try and discuss the problems and then create individual bug reports.
Please note that I have added titles to your issues for easier handling.
Note: I wonder why a search in the database (catalogue) takes longer than a search in the folders. I would have expected this the other way round because in the database all contents are gathered and stored, already. But perhaps this is because you search the database on the content level.
Issue 6: Search results with tabs
Currently the search uses a dialog and a subdialog when searching. This looks very cluttered because you can see two dialogs at a time. I'd suggest to use tabs instead of a sub-dialog. One tab could be "Search" and the other one "Results". Please note that this is a suggestion and not a bug.
Please note that I have added titles to your issues for easier handling.
This should be improved. Without an indication of progress people might think that XnView doesn't work properly and hangs.CameronD wrote: Issue 1: No indication of action when searching database
searching recursively using the catalog: the current pathname stays forever on "DB". For slow searches like XMP content this can potentially result in minutes passing with no indication of anything happening.
This should be corrected. "Dark Theme" still has various flaws, perhaps these flaws could be all gathered (there might be a topic, already).CameronD wrote:Issue 2: Dark Theme: Black text in black field
Same situation as issue 1: the "DB" text is apparently always written in black, so with the dark theme selected no text is visible. When catalog is not used then the pathnames are always written in a contrasting colour text.
Yes, current status of the search should be clearly seen when looking at the dialog. A minor addition: The elipsis in "Finished..." must be removed.CameronD wrote:Issue 3: "Finished" not visible
When more than a small number of files match then the "finished..." text is off the bottom of the window - the user has no indication that the search has finished unless they manually scroll to the bottom of the list to check. There should be an indication of completion in the top area - for example: "Finished : nn files found"
Confirmed. Perhaps when designing a difference was intended but from what I can see there is no difference. So "Cancel" should be removed.CameronD wrote:Issue 4:"Abort" and "Cancel" do the same thing
When a search is active then there are two buttons: "Abort" and "Cancel". They seem to do the same thing.
"Abort" should always be possible. (Perhaps the search must be started in a separate thread to achieve this and in the background the database process might continue because it really cannot be stopped. But at least the user can continue his/her work.).CameronD wrote:Issue 5: "Abort" useless when searching catalogue
"Abort" and "Cancel" buttons do nothing useful if a catalogue search is underway. For example a search for an XMP field value may normally run for 10 minutes. Pressing abort or cancel after the search has started will cause the program to become non-responsive until the time to carry out the full search has passed.
A non-catalogue search returns in a reasonably short time.
Note: I wonder why a search in the database (catalogue) takes longer than a search in the folders. I would have expected this the other way round because in the database all contents are gathered and stored, already. But perhaps this is because you search the database on the content level.
Issue 6: Search results with tabs
Currently the search uses a dialog and a subdialog when searching. This looks very cluttered because you can see two dialogs at a time. I'd suggest to use tabs instead of a sub-dialog. One tab could be "Search" and the other one "Results". Please note that this is a suggestion and not a bug.
Re: 0.84: Search progress and results window
I don't think I said that.Note: I wonder why a search in the database (catalogue) takes longer than a search in the folders.
In my experience an IPTC:caption search using the catalog is much faster than an XMP:description search using the catalog. Both are much faster than not using the catalog. Except when the metadata from 33GB of image files was in the OS disc cache from a previous search: then an XMP-description search without catalog ran faster than with!
The relatively slow speed of catalog-based XMP searches has been pointed out in the past. My guess as to the reason for this slow speed is that the metadata is compressed in the DB, and every record needs to be uncompressed before a string search can be done.
Another guess is that the XMP section is stored as just that - a long xmp-formatted string, and so it has to be parsed in order to extract the field to do the match against.
But, I really don't know.
If I step back a bit, I have to say that none of the bigger bugs actually affect my normal workflow, as I know not to do XMP-based searches.
I suspect some of the problems stem fundamentally from the DB structure, and I would certainly like to see work done on the version 2 DB (which we have discussed elsewhere) in preference to fixing these bugs. However, I have no idea whether this is on Pierre's list of things to do.
Fixing the smaller issues, like clearer indication of termination, would be useful changes no matter the DB structure.
I would be happy if we could pick out the small issues as separate bugs and just move the rest into the "postponed" section, pending DB v2.
Cameron.
Re: 0.84: Search progress and results window
Thank you for your long reply, CameronD. I think issues 1-4 are clear and detailed enough to create individual bug reports. Issues 5 and 6 need more discussion, I think.CameronD wrote:.. I would be happy if we could pick out the small issues as separate bugs and just move the rest into the "postponed" section, pending DB v2.
Re: 0.84: Search progress and results window
yesMy guess as to the reason for this slow speed is that the metadata is compressed in the DB, and every record needs to be uncompressed before a string search can be done.
Yes - fully agree here.I suspect some of the problems stem fundamentally from the DB structure, and I would certainly like to see work done on the version 2 DB...
...(which we have discussed elsewhere)...
http://newsgroup.xnview.com/viewtopic.php?f=60&t=28345
+10000!!!...in preference to fixing these bugs.
DEFINITELY!Fixing the smaller issues, like clearer indication of termination, would be useful changes no matter the DB structure.
I would be happy if we could pick out the small issues as separate bugs and just move the rest into the "postponed" section, pending DB v2.
m. Th.
- Dark Themed XnViewMP 1.6 64bit on Win11 x64 -
- Dark Themed XnViewMP 1.6 64bit on Win11 x64 -
Re: 0.84: Search progress and results window
CameronD, do think you'll find the time to create individual topics for the detected bugs?
Re: 0.84: Search progress and results window
Done, but not fast enough - most have been fixed already.helmut wrote:CameronD, do think you'll find the time to create individual topics for the detected bugs?
On Issue 6, I am happy with the way things are - I think I even prefer it (most of the time).
Issue 2 - I mentioned with issue 1, but not sure how to reproduce, because it is occasional, and not just related to the theme.
Re: 0.84: Search progress and results window
I have edited the first post in this thread to cross reference the individual bug reports, so this page can be moved to closed, afaics
Re: 0.84: Search progress and results window
Great! Thank you for creating individual bug reports, CameronD. This will make handling them much easier.CameronD wrote:I have edited the first post in this thread to cross reference the individual bug reports, so this page can be moved to closed, afaics
Closed