The trace is rather lacking, but from the looks of it tracker isn't working correctly.

Can you confirm tracker is running correctly, try 'tracker status' on the commandline.

buck@archie ~> tracker status
Currently indexed: 610 files, 60 folders
Remaining space on database partition: 86.5 GB (35.25%)
All data miners are idle, indexing complete

Is that helpful?

It indicates that tracker is running at least.

You could try restarting tracker if you haven't done already so: 'tracker daemon -t; tracker daemon -s'.

If that doesn't work try resetting the database: 'tracker reset -r; tracker daemon -s', the re-indexing can take a while.

Resetting the tracker fixed the issue.

Created attachment 335140 [details] [review]
A patch with possible solution

I've also experienced the same issue. I tried to reset tracker, but it only helped for a couple of days.

I investigated this a bit, and figured out that the favorite songs query leads to the error in my case. Here it is:

SELECT ?url
WHERE {
    ?song a nmm:MusicPiece ;
        nie:isStoredAs ?as ;
        nao:hasTag nao:predefined-tag-favorite .
    ?as nie:url ?url .
    FILTER (
      tracker:uri-is-descendant(
        '%(music_dir)s', nie:url(?as)
      )
    )
} ORDER BY DESC(tracker:added(?song))

I noticed that actually nie:url(?as) is equal to ?url. In other similar queries just ?url is used as well. So I did the same here and the issue disappeared.

I've prepared a patch, so please merge it into the development branch if you consider this change valid.

reopen so we don't forget about it until the time we can investigate

I pushed https://git.gnome.org/browse/tracker/commit/?id=22bbc9b339edca0386b7cb85ac4e5d48f2e97a1d on Tracker to fix this. For unclear reasons the sqlite query planner chooses to execute the uri-is-descendant function with a NULL argument even though it could (and most often does) preemptively know that the resultset is empty, I just made the function more permissive for these cases.

That said, I think the patch in comment #5 is right, as we already have the value in ?url, whereas foo:bar(?baz) is resolved independently through a nested select. I would also recommend using STRSTARTS better than tracker:uri-is-descendant, the former can be better optimized.

Sorry for this lingering so long. Patch seemed indeed more logical and is applied, thanks. Also turned all uri-is-descendant into STRSTARTS as Carlos suggested.

This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.

*** Bug 772649 has been marked as a duplicate of this bug. ***