Tracker3 Seems Broken

[simonodd]

Hello, I’m having various issues with tracker, where the index appears incomplete/unstable. This started after my btrfs formatted main drive completely ran out of space to allocate, but still reported lots of free space to the OS, as I have learned is a side effect of btrfs. I ran btrfs balance start / which resolved that issue.

Here’s some of what I tried to troubleshoot tracker.

I ran tracker3 reset --filesystem, and rm -fr ~/.cache/tracker3 for good measure. I then removed all folders from the index and confirmed they were gone with tracker3 index. I disabled all search items in Settings as well, I don’t remember if they automatically mirror the settings set via command line or not.

After restarting, tracker3 status showed around 20 folders and a few hundred files indexed, even though no folders were supposed to be being indexed. I searched for a few random characters and the results seemed to be coming from all over my system. I couldn’t figure out how to just dump a list of every indexed item. tracker3 search / returns empty.

I enabled Music in search settings and let it index again. It showed 12,000 files indexed, which is the size of my music collection, so all seemed good, but nothing appeared in the Music application.

I restarted again, now the index shows 128 files, 19 folders indexed, 03m 15s left. The number of indexed files and remaining time do not change. In Music there appear to be around 130 albums, most of which are missing most of their tracks, but this still means there are many items present in Music that aren’t in Tracker. tracker3 search fails to find many items that are present in Music.

I reset tracker again, the index builds, tracker3 search -m now outputs the short list of songs that appear in Music, but tracker3 status shows all 12000 items indexed again, and 03m 04s left, which never changes.

I’ve been through more iterations of this kind of thing, resetting, restarting, and the index never builds and behaves as it used to.

Sorry for the length, it’s difficult to explain the behavior succinctly, and also difficult to search for! I didn’t find anyone else who seemed to have the exact same problem.

[garnacho (Carlos Garnacho)]

Hi,

The issue is explained at tracker-miner-fs-3 will keep finding DELETED trigger events on BTRFS subvolumes of a mounted FS (#266) · Issues · GNOME / LocalSearch · GitLab and fixed at Use BTRFS_IOC_INO_LOOKUP ioctl to get btrfs subvolume ID (!449) · Merge requests · GNOME / LocalSearch · GitLab.

You forgot to mention the Tracker version, I assume it’s 3.4.x. I’ll get to doing some backports and a new tracker-miners 3.4 release sometime during this week.

[simonodd]

Thanks, sorry for forgetting the version, I’m on 3.5.1.

[sthursfield (Sam Thursfield)]

Thanks for the time spent providing a clear summary of all the diagnosis work you did !

[simonodd]

I had a read through the linked threads and did my best to apply what I learned. If I understand correctly, changing my fstab mounts to use /dev paths instead of UUIDs should work since I’m on 3.5.1. I tried this but the indexing behavior appears much the same. tracker3 status reports 12330 files, the correct number, but tracker3 search -m returns only 202 lines.

My fstab entries just in case:

/dev/sdd3 / btrfs subvol=root,compress=zstd:1,x-gvfs-show 0 0
/dev/sdd3 /home btrfs subvol=home,compress=zstd:1,x-gvfs-show 0 0

Interestingly tracker3 search -f also returns many audio files from the music folder.

I ran tracker-miner-fs-3 with TRACKER_DEBUG=miner-fs-events as suggested in 445, but I don’t see “deleted” events, just this:

Tracker-Message: 16:28:32.924: [Event Queues] Setting up queue handlers...
Tracker-Message: 16:28:32.924: [Event Queues]    cancelled: already one active
Tracker-Message: 16:28:32.924: [Event Queues]  New CREATED event: file:///home/simon/Music/Symphonic%20Choir
Tracker-Message: 16:28:32.924: [Event Queues] Setting up queue handlers...
Tracker-Message: 16:28:32.924: [Event Queues]    cancelled: already one active
Tracker-Message: 16:28:32.924: [Event Queues]  New CREATED event: file:///home/simon/Music/Swedish%20Chamber%20Choir
Tracker-Message: 16:28:32.924: [Event Queues] Setting up queue handlers...
Tracker-Message: 16:28:32.924: [Event Queues]    cancelled: already one active
Tracker-Message: 16:28:32.924: [Event Queues]  New CREATED event: file:///home/simon/Music/Svjata%20Vatra
Tracker-Message: 16:28:32.924: [Event Queues] Setting up queue handlers...
Tracker-Message: 16:28:32.924: [Event Queues]    cancelled: already one active
Tracker-Message: 16:28:32.924: [Event Queues]  New CREATED event: file:///home/simon/Music/Sven%20Gr%C3%BCnberg's%20Proge-Rock-Group
Tracker-Message: 16:28:32.924: [Event Queues] Setting up queue handlers...
Tracker-Message: 16:28:32.924: [Event Queues]    cancelled: already one active
Tracker-Message: 16:28:32.924: [Event Queues]  New CREATED event: file:///home/simon/Music/Sven%20Gr%C3%BCnberg
Tracker-Message: 16:28:32.924: [Event Queues] Setting up queue handlers...
Tracker-Message: 16:28:32.924: [Event Queues]    cancelled: already one active

Which finally ends with

Tracker-Message: 16:29:26.455: Flushing SPARQL buffer, reason: Queue handlers NONE
Tracker-Message: 16:29:26.578: (Sparql buffer) Finished array-update with 594 tasks
Tracker-Message: 16:29:26.579: [Event Queues] Setting up queue handlers...
Tracker-Message: 16:29:26.579: [Event Queues]    scheduled in idle

I’m curious why this started happening after years without modifying fstab or my subvolumes? Did dunning out of allocated space really trigger it or did a package just happen to get updated around the same time or something?

[simonodd]

It appears I was misdirected by my full drive happening at the same time as the update to 3.5.1. Downgrading tracker3-miners to 3.5.0 solved the issue.