Background

A while back, I installed GNOME Music to try out after initially dismissing it years ago. However, it failed to enumerate my Music directory, and I already had cmus for playing Music, so I simply moved on.

Fast forward to last week, and I got myself an old Precision 5520 to experiment with NixOS on. Turns out GNOME Music works there, and it’s rather agreeable to me. So I wanted it to work on my newer Silverblue laptop, where the music failed to enumerate.

TLDR

The issue was a stale tracker library, remediated with localsearch reset.

The Problem with Old Documentation

Every article and forum post I read on this topic told me to run tracker3 reset. Which would’ve been great in 2023, but that command is nowhere to be found now.

The older command, tracker, shows up in this query:

% dnf provides tracker
Updating and loading repositories:
Repositories loaded.
tinysparql-3.10.1-5.fc43.x86_64 : Desktop-neutral metadata database and search
tool
Repo         : @System
Matched From :
Provide      : tinysparql = 3.10.1-5.fc43

But rpm -ql doesn’t list a single thing named “tracker” in the package. However, this is our first clue: Tracker is now TinySparql. But naturally, the homepage for Tsparql is…you guessed it: https://tracker.gnome.org/. Except that the first search result for TinySparql is the now-inaccessable Overview page that’s all about the old Tracker. Lovely.

By absolute chance, I clicked on the link for “Tracker Miners”, the component that previously scoured the filesystem for applicable files, and get redirected to the GNOME Gitlab page for…LocalSearch.

Resolution

Lo and behold, localsearch is installed on my system and seems to have the same interface as the old tracker3 command. For whatever reason, localsearch search --audio turned up all my music, so I started poking around GNOME Music’s source code to see exactly what it wasn’t receiving, but I didn’t get far before deciding to simply reset localsearch, which immediately resolved the issue.