Show duration and other metadata in Dolphin issue

[shag00]

This information is correct for Kubuntu 19.10.

Baloo is the thing that saves all your metadata so it needs to be turned on.
Check status of Baloo:

balooctl status

If it is not running, turn it on:

balooctl enable

Now the bit that is for some reason never mentioned by the clowns who write KDE literature:

KStart>System Settings>Search>File search
enable both Enable File Search and Also index file content
then make sure the location that you store your media is not listed in the box headed: Do not search these locations.

I know I am a little slow but how anyone would deem search criteria as intuitive to metadata display is beyond me.

[jlittle]

I've tried to let baloo do its thing several times over the years, but I've always ended up disabling it, because it starts consuming memory, CPU, or i/o excessively.

I also don't like its design, in that its index is opaque and you're not allowed to see into it. That makes it impossible to work out what is going wrong, such as when the index balloons to hundreds of MB supposedly indexing a few GB, most of which are pictures and music. I suspect the index design does not work well when it's updated, because a small change in your files causes a large part of the index to be rewritten.

IMO it's alpha software, not ready for general use. The way it works and the index structure should be documented, and there should be tools that allow scripts to work with the index, not just an undocumented C++ API.

[shag00]

@jlittle

I put in a bug for this a while ago and they did a fix so what I wrote above actually worked. My baloo just spends 99.9% of the time just sitting at idle with a 6.4Mb db file. It may be time to give it another go if you are on 19.10. Most of the RAM is being used by Google with a stack of open tabs.

[jlittle]

Last December was my last attempt, using 19.10. With content indexing turned off, when baloo would run after a reboot for several minutes, 4 or so, i/o bound on an SSD, and made a 418 MB index. ls -lR ~ | wc -c is only about 3 MB, and takes ⅓ of a second. I'd set up exclusions for .cache, .mozilla, .thunderbird and a few scratch directories of my own. To back up to a USB external drive my / and /home only takes 4 minutes; baloo should be just updating what's changed, and not reading the content.

I just tried again.

$ balooctl disable
Disabling and stopping the File Indexer
$ balooctl purge
Deleted the index database
$ balooctl enable;sleep 1;balooctl status;sleep 1;balooctl status
Enabling and starting the File Indexer
Baloo File Indexer is running
Indexer state: Initial Indexing
Total files indexed: 0
Files waiting for content indexing: 0
Files failed to index: 0
Current size of index is 12.00 KiB
Baloo File Indexer is running
Indexer state: Idle
Total files indexed: 25,168
Files waiting for content indexing: 0
Files failed to index: 0
Current size of index is 12.68 MiB

So, it's working, and built its index quickly. I shall see if it stays that way.

[chimak111]

balooctl purge

That's nice!

Re.

.cache, .mozilla, .thunderbird

I thought dot files and folders were excluded by default.

With Kubuntu 19.10 (5.17.90),

I created a dot folder with an unhidden file in it with a unique word as the file's content. Baloo didn't see it.

I also checked for the "bookmarkbackups" folder (which is in my ~/.mozilla folder) and Baloo didn't see that either.

I created a normal folder in ~/Desktop with an unhidden file in it with a unique word as the file's content. Baloo picked it up.

I haven't made any changes to ~/.config/baloofilerc.

[jlittle]

Re. I thought dot files and folders were excluded by default.

This is (supposedly) controlled by the "index hidden folders" configuration item. I have it set to true, but it seems to have no effect. Searching for 'baloo' finds nothing, despite .local/share/baloo and .config/baloofilerc.
Why? There's no way to see what baloo is doing, except that one might see error messages like

enablereplace called with invalid arguments, docId: 1108101562421url: "/home/john/"

I'm finding baloo flaky at finding ordinary files if I'm working on them. On a save, editors rename the old file and create a new one. baloo should notice, and queue the file for indexing. But sometimes it refuses to see the file unless I do an explicit balooctl index file, even after a disable, purge, enable. Why?

But, this confirmed bug, opened in 2016, means I don't want to use it at all.

[chimak111]

I tried setting index hidden stuff to true quite a while ago and it didn't work.

I still have a non-SSD but can see how baloo's behavior is a problem.

I'll continue using it but with a lot of exclusions (which still doesn't prevent the occasional crash). I think plasma's launcher(s) and krunner use the baloo database to provide me my recently used files.

If there's some neat alternative to list recently used files, I'd love to learn about that. (Of course, each application usually has such a list but having an "external" application-independent way would be nice.)

To access open windows, regularly used files and folders, and text snippets, I use rofi.

[shag00]

Submit a bug if it's not working. The trick with baloo is not just it's config file but the search parameters that I mentioned above.