GNOME Bugzilla – Bug 706027
grilo: don't hammer tracker with a query for every album
Last modified: 2014-04-16 13:53:35 UTC
If tracker didn't give us a thumbnail the first time, it's because it doesn't have one, so there is no point in querying again (especially if we're not really querying for the thumbnail, but only for artist and album fields, which we already know!). Instead, what we want is to resolve the item using the other sources (GRL_RESOLVE_FULL), in particular grl-local-metadata and grl-lastfm-albumart.
Created attachment 251657 [details] [review] grilo: don't hammer tracker with a query for every album
Created attachment 251767 [details] [review] grilo: don't hammer tracker with a query for every album If tracker didn't give us a thumbnail the first time, it's because it doesn't have one, so there is no point in querying again (especially if we're not really querying for the thumbnail, but only for artist and album fields, which we already know!). Instead, what we want is to resolve the item using the other sources (GRL_RESOLVE_FULL), in particular grl-local-metadata and grl-lastfm-albumart.
Review of attachment 251767 [details] [review]: Didn't test this, but looks good (and its a better solution then existing one)
Seif is currently working in album art cache though, so I didn't commit it.
Review of attachment 251767 [details] [review]: When I select an album in the Albums view, a segmentation fault usually happens, otherwise wrong album information is shown. Sometimes when I play a song in the Songs view, a segmentation fault happens after a few seconds. I think it is a good idea to resolve the album art on a fast query - the album art in MPRIS is currently broken because the thumbnail uri is not being resolved.
(In reply to comment #5) > Review of attachment 251767 [details] [review]: > > I think it is a good idea to resolve the album art on a fast query - the album > art in MPRIS is currently broken because the thumbnail uri is not being > resolved. I'm sorry but I don't follow here - the album art is not part of the fast result set, because, well, resolving it is not fast.
(In reply to comment #6) > I'm sorry but I don't follow here - the album art is not part of the fast > result set, because, well, resolving it is not fast. In grilo, album art and thumbnail is the same. I saw that you added it to the keys for "fast resolving" (without Grl.ResolutionFlags.FULL). It is grl-local-metadata that computes for the local thumbnail/album art, though it sometimes fails so the lookup code is in gnome-music too.
(In reply to comment #7) > (In reply to comment #6) > > I'm sorry but I don't follow here - the album art is not part of the fast > > result set, because, well, resolving it is not fast. > > In grilo, album art and thumbnail is the same. I saw that you added it to the > keys for "fast resolving" (without Grl.ResolutionFlags.FULL). It is > grl-local-metadata that computes for the local thumbnail/album art, though it > sometimes fails so the lookup code is in gnome-music too. No, that's not what's happening. Grl.ResolutionFlags.FULL means "ask other sources in addition to this one". We're not asking grl-local-metadata, we're asking grl-tracker, but with the flags, grilo tries all other sources that claim to resolve a key, if the first source did not find a value for it. I removed the flag, so grl-local-metadata (which is slow, because it does IO on the disk and to gvfs) is out of the picture for the initial load of the data. The key is added to the list because grl-tracker sometimes can give a value for it straight away, in which case we can take advantage of the join in the query and avoid more queries later.
Review of attachment 251767 [details] [review]: Agree with Arnel, I usually get: Warning: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed item = self._model.get_value(_iter, 5) or simply None item. No idea how to fix this or why is this happening though
(In reply to comment #9) > Review of attachment 251767 [details] [review]: > > Agree with Arnel, I usually get: > > Warning: g_value_set_object: assertion 'G_IS_OBJECT (v_object)' failed > item = self._model.get_value(_iter, 5) > > or simply None item. No idea how to fix this or why is this happening though That warning means you're putting NULL for a GObject column in the model, which is not allowed.
This is wierd. If I add self._model.get_value(_iter, 5) after self._model.set the whole thing works fine. It seems that we got to 'confirm' that model has really set this value
We've finally fixed this in https://git.gnome.org/browse/gnome-music/commit/?id=5f8afde8daa6ca8f4b4ff666d7aebf97e1d66334 and during albumart refactoring. We're using a strategy similar to the one Giovanni proposed: first we try FAST_ONLY and then fallback to FULL