Re: libmediaart required for Tracker

[Martyn Russell <martyn lanedo com>]

On 07/02/14 13:56, Bastien Nocera wrote:
> Hey Martyn,

Hello Bastien,

> On Fri, 2014-02-07 at 12:13 +0000, Martyn Russell wrote:
> Well, for one, I'd like to understand what it does ;)

:)

> How is this different from using thumbnails to store a file's cover art?

Ultimately media art can be stored in file formats and this library 
provides a way to consistently cache and lookup that media art data. 
Sometimes this is done passing a data buffer found in an MP3 and 
sometimes an actual jpeg filename. This art is then related to a type 
(audio/video/etc) and an artist/album or perhaps both. There are quite 
some heuristics which is why we have a spec¹ on the wiki which Philip 
started a while back and which the library is implementing.

¹ 
https://wiki.gnome.org/action/show/DraftSpecs/MediaArtStorageSpec?action=show&redirect=MediaArtStorageSpec

> Does it do de-duplication based on artist+album?

Absolutely. Back in the Nokia days, we needed this solution for those 
cases where you had an artist and no album or perhaps n tracks for an 
album, all with the same media art in their MP3s. To avoid re-creating 
the cache each time, to save disk space and to have a quick way to look 
it up, we wrote these functions to manage that case.

I would have to check, but I believe we even cover the case where 
thumbnails have already been created in $HOME somewhere and we want to 
link to that art for a set album/artist combination.

> Should box art for,
> say, videos or games be saved in there as well? Or is this simply a way
> to cache "this artist + this album = this pixbuf data"?

Initially it was just for album art, but we've adopted video art too and 
there is a type for that also. Box sets (e.g. Downton Abbey series 1-4) 
might share the same art, so we have allowed for that too.

Essentially there are 2 areas here:

1. Caching APIs (lookup, removal and invalid entity stripping)
2. Extraction APIs (by buffer/file supporting GdkPixbuf / Qt backends)

The important parts here are the *artist* and *title* of the piece. We 
use this to create the MD5sum and link or save a cache based on that.

It was also considered that a $MUSIC_DIR/.mediaartlocal/ path should be 
used for removable media to avoid consecutive extraction of content 
unnecessarily which is why you might see these directories around your 
file system. They are a bit of a nuance actually and there has been a 
bug² recently asking for this to be removed. I am thinking about making 
this optional, I can see the merits from both sides.

² https://bugzilla.gnome.org/show_bug.cgi?id=722795

> It's quite unclear to me where in the stack it lives, and whether it
> should be above or below something like grilo's sources, or totem's
> thumbnailer.

I can understand that. I would say below Totem. Not sure about Grillo.

There is functionality to download media art from a service too, which 
Nokia was doing on the N9 and you can see remnants of that in the code³ 
base:

³ https://git.gnome.org/browse/libmediaart/tree/libmediaart/extract.c#n1031

This is actually redundant currently because there is no such service in 
GNOME AFAIK. However ideally, it should provide a way to download media 
art as an alternative.

I am unfamiliar with the innards of Grilo so, I can't say if it competes 
or duplicates efforts there.

I knew there was a thumbnailer for GNOME some years back, I thought it 
was in GnomeVFS. However, I don't know whatever happened to it. Is it 
now in Totem? In the Nokia days we also used a different thumbnailer (of 
which I forget the name now, Philip would know) in some cases to 
interpolate camera taken videos/images for their thumbnails, but that's 
a slightly different use case than here.

While the library is fairly young, I think it could use some 
improvements in a number of places.

I've always thought this is an area of GNOME which languishes a bit and 
I am happy for people to add their features or help out. Perhaps even to 
use other libraries in the stack that improve the project?

Anyway, it's out there for others to use. If it's already redundant 
Bastien, we can fix that too and improve Tracker/GNOME Music/etc 
instead. This dep on Tracker is in master, so nothing has been released 
yet (other than libmediaart) :)

--
Regards,
Martyn

Founder & Director @ Lanedo GmbH.
http://www.linkedin.com/in/martynrussell