This bug is a synthesis of some already opened bug in the BTS : https://bugs.kde.org/show_bug.cgi?id=330989 https://bugs.kde.org/show_bug.cgi?id=333433 https://bugs.kde.org/show_bug.cgi?id=333655 https://bugs.kde.org/show_bug.cgi?id=333743 https://bugs.kde.org/show_bug.cgi?id=332195 and maybe more. The claim that "baloo should not get into the user way" that is the argument for not allowing to disable the automatically indexing process is obviously ruled out by the behaviour of the baloo system. As a matter of fact, baloo is choking my HDD IO system since more than 36 hours now, not letting me do my usual work easily with major slowdown of my computer. So it gets into my way. It could depend of the data configuration into ones computer, mine is a messy heap of data for a total > 200G. Consider it is probably what drives baloo in its current state to its boundaries. Now, about fine tuning : I am really surpised of the utter simplicity showed by the configuration interface for the baloo process. (Systemsettings -> Desktop search). Allowing only to select the folder to be scanned is fine, but far from being enough. So here I put some suggestions that could help to solve some of the bugs reported above, while increasing the usability of baloo. 1) Fine tuning on files One should be able to exclude from indexation certain types of files. I think especially about for exemple, size limitation for indexing, as suggested by vHanda. But one could choose also to not index videos, music, text, pdf document, whatever type of document could come into play. One should also be able to exclude/include folder to be indexed with check boxes in a given filesystem tree (~/ but could be another place). One should as well be able to choose the place to store metadata. And one should be able to do that without manually write this into a text rc configuration file. 2) Fine tuning on IO and cpu usage One should be able to evaluate the time the baloo process should do to index everything in a given folder, and provide a progress bar for the user. Something like : "the indexing process is going to take about 3 hours. Do you want still to launch it ? Yes/No/Exclude some more directories from the indexing process" One should as well be able to slow down the process of reading the hard drive. This is not normal that the process consumes so much computer resources. Probably it will mean internal optimization really difficult to make, about which I am not aware so I cannot say much about this. Reproducible: Always Steps to Reproduce: 1. Run baloo on my hard drive
I have same problem with my system. I know I have a lot of data there, but still, Baloo shouldn't behave like that. And, of course, fine tuning is much needed.
*** Bug 334726 has been marked as a duplicate of this bug. ***
FIne tuning of baloo can be done using kcm_baloo_advanced, it allows for mime filters and file filters. It is available from AUR for archlinux, which contains a link to the git of the source project: https://aur.archlinux.org/packages/kcm_baloo_advanced/
I face this bug too, it's horrible. Running "balooctl check" reproduces this issue everytime. This bug does not happen with GTK based desktops when using synapse(updatedb?). I assume if that has the ability to index all the files without lagging, then so should baloo.
(In reply to David Kremer from comment #0) > 1) Fine tuning on files > One should be able to exclude from indexation certain types of files. I > think especially about for exemple, size limitation for indexing, as > suggested by vHanda. But one could choose also to not index videos, music, > text, pdf document, whatever type of document could come into play. This doesn't really make sense IMO. What's the use case? > One should also be able to exclude/include folder to be indexed with check > boxes in a given filesystem tree (~/ but could be another place). Already implemented. :) > One should > as well be able to choose the place to store metadata. And one should be > able to do that without manually write this into a text rc configuration > file. What's the use case? Why? > One should be able to evaluate the time the baloo process should do to index > everything in a given folder, and provide a progress bar for the user. > Something like : "the indexing process is going to take about 3 hours. Do > you want still to launch it ? Yes/No/Exclude some more directories from the > indexing process" This is already (more or less) implemented in the File Indexing Monitor page of the Info Center app. > One should as well be able to slow down the process of reading the hard > drive. This is not normal that the process consumes so much computer > resources. Probably it will mean internal optimization really difficult to > make, about which I am not aware so I cannot say much about this. Already tracked by separate bug reports.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!