GNOME Bugzilla – Bug 439178
TST shows word hits instead of file hits
Last modified: 2009-01-14 13:28:57 UTC
Please describe the problem: On its results display, TST shows word hits instead of file hits. Steps to reproduce: 1. create some file 2. enter some word in that file and check number of hits with TST 3. enter same word again in that same file and search again with TST Actual results: TST will display an increased number of hits. Expected results: Number of hits should represent number of files in which a specific search term occurs in, NOT the number of occurences in each file. number of word hits should only be kept internally by the indexer, perhaps for ranking purposes. Does this happen every time? Yes Other information: A related problem: On deleting that particular file (the one with repeated occurences of the search term), the number of hits shown on TST remains the same, only without files shown. It does not help running trackerd --reindex nor deleting .local/share/tracker because the problem remained easily reproducible once following the above 3 steps.
I believe it's the same bug that causes t-s-t to show broken results list. It says "Results 1-10 shown", but only three matches are shown, or sometimes nothing. Attaching a couple of screenshots to illustrate. Additionally, it seems that once you go a couple of result pages further and leave it for some time, it will display results correctly once you revisit those pages, which would suggest some kind of miscommunication with tracker and stuff being fetched as you go. FWIW, the HD is constantly busy as I write this, and has been this way ever since I run a search in t-s-t.
Created attachment 96175 [details] Wrong results display -- no files visible Taken with t-s-t 0.6.2
Created attachment 96176 [details] Wrong results display -- too few files visible Taken with t-s-t 0.6.2
Heavily tested, and this behavior doesn't reproduce at all with current SVN (30 dec 07) This bug should be closed.
no, this is present in 0.6.6, which is much more recent afaik.
Trying with svn trunk, this problem doesn't appear anymore, so I think this bug is obsolete