https://bugs.kde.org/show_bug.cgi?id=438074
--- Comment #8 from tagwer...@innerjoin.org ---
(In reply to Martin Tlustos from comment #7)
> Copying the content of a afflicted folder to a new folder doesn't help, the
> new folder is reindexed as well.
So you've copied the problem - and it seems to be "a file problem" :-)
I know that baloo_file_extractor deals with batches of files, 40 at a time. I
don't know if it commits "what it's learned" after each file or at the end of
the batch but I can imagine that it's committed at the end of the batch.
If there's a (bad enough) failure indexing one of the files, it may be that no
"content index" information for the batch is written to the index. The indexing
of these files is incomplete so baloo, after a "balooctl check", tries again.
It should be that baloo recognises such failures, "balooctl status" does give a
count of "Files failed to index". Maybe that's not working as it should.
Anyway, it might be possible to see some evidence...
For one of the files that are repeatedly reindexed, have a look with "balooshow
-x ..." and what's listed under the "Internal Info":
If this is very basic ("Terms", "File Name Terms", "XAttr Terms"),
these are what "baloo_file" writes during its initial scan.
If you see a longer list of "Terms", words that appear within the
document, or possibly a "Width:" and "Height:" for an image (could
be loads of different fields for an image file), then this is
information collected and written by "baloo_file_extractor".
So compare what "balooshow -x .. " gives for your repeatedly reindexed files -
and compare that to what "balooshow -x" gives for files that have been indexed
OK.
My guess is if you see only "basic information" then something's failed and the
data's not been committed. After that it might be a question of trying to
"narrow down" the file/files that are causing the problem.
--
You are receiving this mail because:
You are watching all bug changes.
