Re: [Tracker] Video thumbnailing

[Sam Thursfield <ssssam gmail com>]

On Tue, Oct 11, 2011 at 9:17 AM, Martyn Russell <martyn lanedo com> wrote:
> On 11/10/11 09:12, Jens Georg wrote:
> > > > Would a moviedb miner make sense?
> > >
> > > It seems like at this point we'd be reimplementing Grilo. Perhaps a
> > > better idea would be to recommend applications fetch media art through
> > > Grilo, and let Tracker only deal with locally stored images.
> >
> > Well. What about the other meta-data? Sure you could get that from
> > grilo, but you'd need to query two stores again.
>
> I actually don't think it makes sense to go through Grilo. We've had the
> idea of querying internet services for more information before and I think
> we should just do it.
>
> In my mind, I see Grillo as something that works with us not something we
> should work with to obtain information. I know very little about it though
> so I am happy to be enlightened :)

I don't think it makes sense at all for Tracker to use Grilo. However,
the purpose of Grilo is to aggregate multiple providers of media and
metadata, so it's worth at least being aware of what we're
duplicating. For example, in the case of media art:

- Tracker already picks up embedded/external art stored on the filesystem
- Grilo already supports querying album art from last.fm

It seems sensible here to add to Grilo support for querying media art
from Tracker (which at present is simply looking in .cache/media-art
anyway), and suggest users go through Grilo if they want media art. Of
course, if this is the only place where it makes sense then maybe it's
not worth the extra layer. In the case of general metadata, for
example pulling track metadata from Musicbrainz, this of course should
go into Tracker (it has to, if we want to be able to search it)

Grilo's API is a lot simpler and less verbose (for simple queries)
than using libtracker-sparql directly, I recommend taking a look (and
showing it to anyone who moans about having to use sparql :)