GNOME Bugzilla – Bug 766505
search in gnome-music raises tracker warnings
Last modified: 2016-11-02 12:22:09 UTC
The queries for artist/album/song are broken since the query rework in 2.19 it seems. Ironically it seems to be commit https://git.gnome.org/browse/gnome-music/commit/?id=0b169a97f22305c4822a532a08aaa80f615cc336 that broke it.
Broken exactly how? Are you using Tracker master or 1.8? I can see missing songs/albums when running tracker 1.9/master, but AFAICS it all comes back normal if running tracker 1.8. Trying with the combinations, I've figured out the difference in behavior is triggered by tracker-extract, running everything from master except tracker extract brings all songs in the views. Doing the opposite (just running tracker-extract from master) results in missing albums. So it seems something with the metadata, I tracked it down to commit 79af6adf6ee3. Reverting it brings back all songs in the music view here. I'm still unclear why though, the metadata is most similar for files I see missing here. Could you confirm? In that case, please reassign to tracker and retitle :)
The commit is https://git.gnome.org/browse/tracker/commit/?id=79af6adf6ee3
Created attachment 327974 [details] errors when querying artist and album Tried with tracker 1.8.0 (release) and 1.9 (git). Output is as in attachment when trying to search specifically for artist and album. Could still be a local set-up problem if you can't reproduce.
The full warning is: (gnome-music:10772): Grilo-WARNING **: [tracker-source-request] grl-tracker-source-api.c:501: Could not execute sparql query id=3: no such column: nmm:MusicAlbum_nmm:albumArtist3.nmm:albumArtist This is not due to sparql, but apparently an error in libtracker-sparql (that's not an ontology warning, but a sql engine one). For added fun, running the same queries with "tracker sparql" brings no warnings. Reassigning and retitling.
Created attachment 328707 [details] [review] libtracker-data: Refine BIND() variable mapping The implementation of BIND() introduced an special case in the way we construct the result columns in selects (Handled in commit 64b54a7784). This special case however turns out wrong when the resolved variable is used both in and outside the BIND() statement. So, admit the nature of this hack and special case it altogether, the check was too iffy when there is really one situation where this makes sense.
I also forgot to mention, the issue mentioned in comment #1 is also fixed, commit 6dc2c858561
Pushed to master at the moment, a candidate for 1.8 though. Attachment 328707 [details] pushed as 4e5cc9b - libtracker-data: Refine BIND() variable mapping
Sorry, I didn't get around to testing the patches earlier. However, current master -including this patch- doesn't solve the problem for me. I still get the exact same warnings as in comment #3 .
Ok, I did some digging and figured this is probably due to switching to FTS5 and FTS5 defining syntax for the colon symbol ( https://sqlite.org/fts5.html#full_text_query_syntax ). Music does it's fts searches by searching for the full iri's (?) ( eg. https://git.gnome.org/browse/gnome-music/tree/gnomemusic/query.py#n855 ), the semicolon messes with the sql query it looks like. This would mean we need to rewrite the queries. Any thought on this?
Created attachment 338890 [details] [review] query: Quote column names in fts:match clauses The colon in the column name seems able to confuse the FTS parser, let's help it better by enclosing the column name with double quotes, which is valid syntax according to the FTS5 syntax reference.
Moving back to gnome-music, as the FTS syntax is pretty much offered as-is, there's not much further involvement from tracker here.