How to see Tracker graph contents using cli, for a specific app

Platform
1

I’m trying to figure out how Tracker works as a database for applications, in particular Gnome Music.

I have a song that is in a playlist, and within Gnome Music there is a sparql query that queries for a specific song within a playlist:

In trying to debug something around this, I am attempting to use the tracker3 cli. However, if I query a song that I know is in the playlist, with:

tracker3 info file:///home/jon/Music/The%20Beatles/Abbey%20Road/01.Come_Together.flac

I don’t see any results that contain nmm:Playlist

likewise, if I attempt to display all playlists on my system, like:

tracker3 sparql --dbus-service="org.freedesktop.Tracker3.Miner.Files" -q "SELECT ?playlist { ?playlist a nmm:Playlist } "

I get no results.

I also tried tracker3 sparql --dbus-service="org.freedesktop.Tracker3.Miner.Files" -q "SELECT ?playlist { GRAPH tracker:Audio { ?playlist a nmm:Playlist } } "

because I suspect (but could be very wrong) that GRAPH tracker:Audio will make it query the graph specific to Gnome Music, which perhaps is where the playlists are stored, but that also returns no results.

2

Hi Jon. The secret is that apps have their own databases. So you need to find where your GNOME Music app is storing its data, and pass that location to tracker3 --database=.

For example I have gnome music installed via flatpak, so its data is hidden in ~/.var. With this command I can see everything it has stored:

tracker3 export --database ~/.var/app/org.gnome.Music/cache/gnome-music/db

If you have gnome-music installed via your package manager then the corresponding path is probably ~/.cache/gnome-music/db.

In the old days of Tracker 2, there was a single “Tracker database” which stored everything. But since Tracker 3, apps can easily create their own database. The filesystem index created by Tracker Miner FS is one example, and the GNOME Music database is another. I wrote about this a while back here - Tracker 3.0: What’s New? – Sam Thursfield

3

Hi Sam, that’s very helpful, thanks.

I’m getting:

Could not establish a connection to Tracker: Database version is too new: got version 28, but 27 is needed

when I run:

tracker3 export --database ~/.var/app/org.gnome.Music.Devel/cache/gnome-music/db/

Have you encountered that before?

4

If you’re using GNOME Music from Flatpak, it could be that the version of libtracker-sparql inside the Flatpak sandbox is newer than the version of libtracker-sparql on your host OS. Make sure your host OS is at the latest version.

5

I see this in gnome music meson.build:

dependency('tracker-sparql-3.0', version: '>= 2.99.3')

and running tracker3 --version on my system (debian 12) displays :

Tracker 3.4.2

So it seems like I have an acceptable version of tracker.

6

That line in meson.build is showing you the minimum version required. That doesn’t tell you which version is actually in use.

If we look at the Flatpak manifest for org.gnome.Music you can see it declares a dependency on GNOME 45 runtime. Now let’s look in gnome-build-meta at the 45.0 tag. The sdk/tracker element is building Tracker 3.6.0.

The actual Tracker SPARQL database versions are defined here in tracker-db-manager.h. Seems the version bump happened in 3.6.0 so that we could improve the ranking algorithm for full-text search results.

So you can either update your host OS to something with GNOME 45 and Tracker 3.6.0, or try one of these workarounds:

  • run tracker3inside the Flatpak sandbox, e.g. flatpak run --command=/bin/bash org.gnome.Music
  • build libtracker-sparql from source and install it into ~/.local; there are some instructions in the README
7

Ok, I’ve got it working by using Gnome Boxes (how did I not know about this it’s awesome?!) to run a beta release of Fedora 39 which uses Gnome 45.

Thanks!

1 Like
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.