This week I've been focusing on album art support. It was actually Aren's idea that, from the beginning, we should create pluggable interfaces for things like dynamic playlists, album art, lyrics, devices, and etc. This means that album art support wouldn't be hard coded to one place like Amazon, but anyone could add a plugin to support album art from anywhere. Currently, there are three album art plugins: local search, which checks local directories for image names like 'cover.jpg' and etc., Amazon, and Last.FM. The idea is that each plugin will be searched in order until something is found. Also Aren's idea: the order that each plugin is searched should be user definable.
So, this week's tarball includes the following:
- Album Art Manager (it's basically just like the old one)
- Preferences page to allow you to drag and drop the album art search methods

Also, I've uploaded the current Exaile 0.3 API Documentation. Note that it's probably going to change.

You should include the option to pull album art straight from id3 / ape tags. I think vorbis supports it now too, but not sure.
Also, if nothing local is found, the option to automatically save the "remote" covers (from amazon or last.fm) locally would be nice.
;)
This would probably be pretty easy with the new plugin system... however, there are a few issues I could see coming up with the automatic saving portion:
If lastfm or amazon covers are ordered before the tagcover plugin, then amazon and lastfm would be searched prior to checking if there is art in the tag. What happens at this point? Should the remote cover only be saved if there isn't already art stored in the tag? Keep in mind that these are plugins that have no idea of the state of the other plugins, so we can't really make an edge case for one plugin.
That's understandable, Adam. I wasn't suggesting any special checks nor think there should be any. I'm assuming that once something is found, it doesn't try the others. If that is the case, then just stick with the order method.
The only thing that you might wish to do is add something in the description to mention ordering suggestions.
Like, for a tags fetcher, mention it won't do much good if it isn't first, and for a local filesystem searcher, that placing it after remote fetchers is less than ideal.
Outside of that, I believe in letting users do what they want, even if it's something illogical and stupid. It's really not worth extra complexity trying to enforce common sense on those few % of the population that have none.
Just like I thought, it was going to be easy. I've implemented a 'tagcover' plugin that can read album art from id3 tags for mp3s (eventually I'll extend it to write, and possibly support other types of tags). It's been pushed to the bzr repo.
@Villamar: It's not the reading of tags that I see as being a problem, it's the writing of tags. Reading is easy, and yes, it should be common sense.
The problem is determining when it's acceptable to write the art to the tag automatically. Should it overwrite existing tags?
Ahh, I misunderstood that thread of questioning. I would say not to overwrite by default, maybe have a 3-way toggle, like 1) Disable / Never (over)write. 2) Only write if not existing. 3) Always overwrite.
I hesitate to mention a prompt option as one would have merit, but music is often listened to unattended or in the background and I would think it not worth the effort of adding timers and all that.
The other alternative is to leave out write capability from that plugin and add it to the tageditor instead. Have a section for album art and allow downloading and writing to all/missing from cache or fetch now sort of think, placing the onus on the user by having them make a conscious act.
Yeah, I think a conscious act method is the best route in this case.
Heh, at this point, I think this is the first media player that I've used that supports this feature. Interesting to see which tracks in your library already have album art :)