Re: libmediaart required for Tracker

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.


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.


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

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:


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) :)


Founder & Director @ Lanedo GmbH.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]