> Note that (at least in my case) the two tags still remain, even though there's no file in the whole system that uses that tag
The Tags shown the left hand panel depend on baloo having "caught up" with any changes - new tags, changed tags, old tags etc.

It can be that a "balooctl check" nudges baloo to go back and double check for changes.

There's a tracking bug - Bug 454952 - that tries to collect and summarise the various tag "eccentricities "...

(In reply to tagwerk19 from comment #1)
> > Note that (at least in my case) the two tags still remain, even though there's no file in the whole system that uses that tag
> The Tags shown the left hand panel depend on baloo having "caught up" with
> any changes - new tags, changed tags, old tags etc.
> 
> It can be that a "balooctl check" nudges baloo to go back and double check
> for changes.
> 
> There's a tracking bug - Bug 454952 - that tries to collect and summarise
> the various tag "eccentricities "...

If the tag on the left-hand panel depends on Baloo, then what do the Tags on the All Tags folder (tags:/) depend on? Because now it seems these two groups of tags are different. And the bug I experiencing seems to persist across restarts, I think it's mostly a problem with Dolphin (or Baloo?) because I still can add or remove a tag from a file, but Dolphin stops keeping track of it anymore, which is kinda annoying, and for that note, is there a way to "fix" this like, for example, a graphical glitch on Plasma somehow can be fixed by turning off and on the compositor (the effect stuff) but just for refreshing and resyncing the Tags?

There's layers....

If you want to start at the bottom and check, the tags are stored in xattr and you can see them with:

    getfattr -d your-tagged-file.txt

You'll see your tags listed as a "user.xdg.tags" comma-separated list of values. If you've added tags through Dolphin you can see whether they've got to the filesystem with a "getfattr"

You can check whether baloo has indexed the file with balooshow:

    balooshow -x your-tagged-file.txt

(look for the "XAttr Terms" line), if that's worked, then you should be able to find the file when searching by the tag:

    baloosearch tags:"yourtag"

If it's gone wrong up to here, then there's an issue with baloo.

You don't say what sort of filesystem you are using. It's possible that your "baloosearch" would show several matches for each file, that can happen if you are using BTRFS and the best bet then to recreate the index, try

    balooctl purge

(You might need patience while the files are reindexed)

Dolphin queries baloo to get its "tag folders", however it caches results and it can be that it gets hung up with stale results. It should show the same results in the left hand panel that you see when you manually open "tags:"

Possibly an F5 would refresh the data but very likely not, closing Dolphin and relaunching can help but it's a bit distribution dependent, sometimes there's a copy of Dolphin running quietly in the background.

If you want to look deeper, there are likely "tags.so" processes running, these are the processes that cache the results from baloo. If you've got more than one "tags.so" process, there's a chance that the different processes are holding different sets of results (this happened a while back, possible it's been fixed...)

(In reply to tagwerk19 from comment #3)
> There's layers....
> 
> If you want to start at the bottom and check, the tags are stored in xattr
> and you can see them with:
> 
>     getfattr -d your-tagged-file.txt
> 
> You'll see your tags listed as a "user.xdg.tags" comma-separated list of
> values. If you've added tags through Dolphin you can see whether they've got
> to the filesystem with a "getfattr"
> 
> You can check whether baloo has indexed the file with balooshow:
> 
>     balooshow -x your-tagged-file.txt
> 
> (look for the "XAttr Terms" line), if that's worked, then you should be able
> to find the file when searching by the tag:
> 
>     baloosearch tags:"yourtag"
> 
> If it's gone wrong up to here, then there's an issue with baloo.
> 
> You don't say what sort of filesystem you are using. It's possible that your
> "baloosearch" would show several matches for each file, that can happen if
> you are using BTRFS and the best bet then to recreate the index, try
> 
>     balooctl purge
> 
> (You might need patience while the files are reindexed)
> 
> Dolphin queries baloo to get its "tag folders", however it caches results
> and it can be that it gets hung up with stale results. It should show the
> same results in the left hand panel that you see when you manually open
> "tags:"
> 
> Possibly an F5 would refresh the data but very likely not, closing Dolphin
> and relaunching can help but it's a bit distribution dependent, sometimes
> there's a copy of Dolphin running quietly in the background.
> 
> If you want to look deeper, there are likely "tags.so" processes running,
> these are the processes that cache the results from baloo. If you've got
> more than one "tags.so" process, there's a chance that the different
> processes are holding different sets of results (this happened a while back,
> possible it's been fixed...)

I see, yes, I'm using BTRFS, I apologize for not mentioning it, and indeed `balooctl purge` seems to fix things, but now it seems that baloo doesn't even indexing or monitoring any changes after a purge and then a restart.

I restart the computer after executing `balooctl purge` (wait till it finishes the purge), and sure enough the Tag is now gone, and I waited a little while until baloo have 100% indexing my home folder, and then trie to modify a tag of a file in my home folder, the tag seems to be applied and I can see it through `getfattr` command, but baloo doesn't seem to detect this changes and stays at "Idle" on the `balooctl monitor` command resulting in no tags added to Dolphin collection, I think I need some time to see the behaviour of these two software, but I guess it's the bug?

Also, sorry if somehow I make this bug report section like a forum discussion and break any guidelines.

> ... sorry if somehow I make this bug report section like a forum discussion and break any guidelines ...
First off, no worries. The perception and description of a bug grows and changes with time. That should be expected...

> ... but baloo doesn't seem to detect this changes and stays at "Idle" on the `balooctl monitor` command ...
If you were doing "content indexing" and editing a file (that might happen if you were changing embedded tags in an MP3 or JPG), then baloo would need to open the file, read the metadata and index it.

With 'xattr', the info is "filesystem metadata", akin to the file modification time. Baloo just picks this up and you won't see the file appearing in "balooctl monitor". The good news is that you can make use of tags even if you are not doing content indexing...

What does "balooshow -x your-tagged-file.txt" give you? Do you get any (some? all?) details?

(In reply to tagwerk19 from comment #5)
> > ... sorry if somehow I make this bug report section like a forum discussion and break any guidelines ...
> First off, no worries. The perception and description of a bug grows and
> changes with time. That should be expected...
> 
> > ... but baloo doesn't seem to detect this changes and stays at "Idle" on the `balooctl monitor` command ...
> If you were doing "content indexing" and editing a file (that might happen
> if you were changing embedded tags in an MP3 or JPG), then baloo would need
> to open the file, read the metadata and index it.
> 
> With 'xattr', the info is "filesystem metadata", akin to the file
> modification time. Baloo just picks this up and you won't see the file
> appearing in "balooctl monitor". The good news is that you can make use of
> tags even if you are not doing content indexing...
> 
> What does "balooshow -x your-tagged-file.txt" give you? Do you get any
> (some? all?) details?

When I try the command `balooshow -x /path/to/my/file.extension` it shows something like this

`36acae10000002d 45 57330401 /path/to/my/file.extension: No index information found`

But the getfattr returns the applied tags just fine.

And I think I found out why, for some reason, even though Baloo didn't do anything, idling, with the indexing progress at 100%, it just becomes unresponsive, it happened for the first 2 purges and restart attempts, and to note that at the time only my home folder being indexed and the hidden folder/file is **unchecked**. What I also found is `balooctl monitor` works just fine but something like `balooctl status` took quite a long time to return the result, and opening the `Search` settings on the KDE System settings took around the same time before showing up the page, and the status is Idle at 100% indexed while executing `balooctl disable` only says disabling and stopping the baloo but seems failed to do so, and with the apparent result when I do `balooctl purge` because it is waiting for the baloo to stop, but at the end of the wait it says failed to stop baloo. But after that, I do some purge and restart cycles again and it seems Baloo is well-behaved now, so maybe the actual bug was Baloo sometimes can become unresponsive and it persist across restarts.

> ... 'balooctl status' took quite a long time to return the result ...
Balooctl is looking through the index and counting the files that still need to be indexed - at the same time as baloo is indexing and adding results to it. The two do a little dance as to who gets access to the file....

One thing to double-check:  Watch out whether you are using symlinks. Baloo does not follow these when it discovers what needs to be indexed. If you've created your text file in a folder "elsewhere" in your system and symlinked to it, then it is not going to be indexed.

Second, there's a recent change (something that is being looked at again at the moment) that caps the amount of memory that baloo can use.  You might want to check the:

    /usr/lib/systemd/user/kde-baloo.service

file (if it exists...) If there's a memory limit is there as a:

    MemoryHigh=512M

line, you can try changing it to:

    MemoryHigh=50%

and see whether the indexing changes.

However the underlying problem is likely to be with BTRFS (and the fact that when you reboot your disc might be mounted with a different device number - and this makes baloo think that all your files are "new files"). It's worth looking at Bug 470665.

(In reply to tagwerk19 from comment #7)
> > ... 'balooctl status' took quite a long time to return the result ...
> Balooctl is looking through the index and counting the files that still need
> to be indexed - at the same time as baloo is indexing and adding results to
> it. The two do a little dance as to who gets access to the file....
> 
> One thing to double-check:  Watch out whether you are using symlinks. Baloo
> does not follow these when it discovers what needs to be indexed. If you've
> created your text file in a folder "elsewhere" in your system and symlinked
> to it, then it is not going to be indexed.
> 
> Second, there's a recent change (something that is being looked at again at
> the moment) that caps the amount of memory that baloo can use.  You might
> want to check the:
> 
>     /usr/lib/systemd/user/kde-baloo.service
> 
> file (if it exists...) If there's a memory limit is there as a:
> 
>     MemoryHigh=512M
> 
> line, you can try changing it to:
> 
>     MemoryHigh=50%
> 
> and see whether the indexing changes.
> 
> However the underlying problem is likely to be with BTRFS (and the fact that
> when you reboot your disc might be mounted with a different device number -
> and this makes baloo think that all your files are "new files"). It's worth
> looking at Bug 470665.

I do use symlinks but when I found this issue I was editing a normal file in the root of my home folder. Also, I assume that Baloo won't follow/index the symlinked folder if the folder is not explicitly added to the index list on the KDE Settings, right? Because after the Baloo behaved normally, I can add the symlinked folder into it and it index the folder just fine.

Let's say the folder is located at `/mnt/tier_1/diagrams` and I symlinked it to the home folder, so the path would look like `~/diagrams`, and I add `~/diagrams` explicitly into the indexed folder on the File Search settings and it now indexed and detect tag changes to the file inside this `diagrams` folder, whether I change it from `~` or from `/mnt/tier_1`

I checked and the service file exists and it also contains the `MemoryHigh` config with the same value, is it the limit of system memory that Baloo can use? Does it have anything to do with the Baloo index size through `balooctl indexSize`? Also, does 50% means 50% of the total system memory?

And the bug you mentioned seems interesting because I've never experienced Baloo reindexing my partition again and again (or either because it's an SSD so it didn't really matter or I just don't pay any attention), even when previously it was non-responsive it just stays idle, I forgot to check the CPU usage but it seems that it doesn't do anything since I have quite underpowered and relatively old CPU (i3-8100) and doesn't feel anything become sluggish or my fan ramping up when start-up, but just the Baloo itself quite slow to respond (among other things I've stated and explained), but definitely will check the next time when I'm going to do a restart.

(In reply to Dean Rikrik Ichsan Hakiki from comment #6)
> When I try the command `balooshow -x /path/to/my/file.extension` it shows something like this
>  
> 36acae10000002d 45 57330401 /path/to/my/file.extension: No index information found
Baloo doesn't know of the file.

Maybe because it is blocked doing something else (do you see the baloo_file process working solidly if you look in htop?) It could be that changing MemoryHigh to 50% would get things moving.

(In reply to Dean Rikrik Ichsan Hakiki from comment #0)
> ... except `kf.kio.workers.tags: "tags:/Test" stat() invalid url`, when trying to open the
> "tag folder", `Test` here is what the Tag should be renamed to, not the original/previous name ...
I can get the same error

If I apply a tag "Test" to a file, open "All tags" from the Places side panel. Dolphin shows me a "Tests" folder in the main panel and "Test" as a tag in the Places side panel.

If I right click on "Test" in the main panel, I can rename it to "Fred" but the "Test" in the side panel does not change. I can click on this "Test' and get your kf.kio.workers.tags error.

This one is a bug...