0.84: Search progress and results window

[CameronD]

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

[helmut]

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.)

[CameronD]

I will split them up eventually, although I suspect 1 and 5 might be strongly linked - but the others are certainly discrete problems.

[helmut]

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.

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 improved. Without an indication of progress people might think that XnView doesn't work properly and hangs.

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.

This should be corrected. "Dark Theme" still has various flaws, perhaps these flaws could be all gathered (there might be a topic, already).

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"

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.

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.

Confirmed. Perhaps when designing a difference was intended but from what I can see there is no difference. So "Cancel" should be removed.

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.

"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.).
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.

[CameronD]

Note: I wonder why a search in the database (catalogue) takes longer than a search in the folders.

I don't think I said that.
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.

[helmut]

.. 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.

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.

[m.Th.]

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.

yes

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...

Yes - fully agree here.

...(which we have discussed elsewhere)...

http://newsgroup.xnview.com/viewtopic.php?f=60&t=28345

...in preference to fixing these bugs.

+10000!!!

triumphant-smiley-emoticon.png (9.15 KiB) Viewed 1259 times

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.

DEFINITELY!

[helmut]

CameronD, do think you'll find the time to create individual topics for the detected bugs?

[CameronD]

CameronD, do think you'll find the time to create individual topics for the detected bugs?

Done, but not fast enough - most have been fixed already.

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.

[CameronD]

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

[helmut]

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

Great! Thank you for creating individual bug reports, CameronD. This will make handling them much easier.

Closed