Fetch cover art from last.fm

[GoogleCodeExporter]

A pain, and not useful to me personally, but frequently requested. 

Original issue reported on code.google.com by ian.ol...@gmail.com on 24 Dec 2009 at 3:24

[GoogleCodeExporter]

Aaron checked in a working implementation in revision 7a6dcc6b6b.

I just want to do some housekeeping to minimize startup time before I consider 
this
complete.

Original comment by ian.ol...@gmail.com on 20 Mar 2010 at 4:28

• Changed title: Fetch cover art from last.fm
• Changed state: Started

[GoogleCodeExporter]

This is actually something I am working on right now. I am trying to see if I 
can 
properly update the ID3 tags within the MP3 file to prevent having to fetch the 
covers the second time it starts. This would obviously need to be a user 
configurable option since some users may we weary of letting the software make 
any 
changes to thier mp3 files. 

Right now it is semi-working. It writes an image to the ID3 tag and on second 
run it 
doesnt re-request the image from the server but the image it writes is 
completely 
black. I have to do some more debugging to figure out what is going on.

Original comment by aaron.ri...@gmail.com on 21 Mar 2010 at 6:21

[GoogleCodeExporter]

Cool!  You could consider just saving it as cover.jpg in the folder, too, which 
would
have the same effect and wouldn't require altering the mp3.

Original comment by ian.ol...@gmail.com on 21 Mar 2010 at 5:15

[GoogleCodeExporter]

Another speedup idea I had:

The really slow last.fm lookups are the ones that fail for whatever reason.  It 
might
be an obscure live album, or might have no album name at all.  For these, it 
might be
good to save the fact that last.fm didn't have art, so we don't bother looking 
them
up again.  The cache file is probably the logical place for that.

Original comment by ian.ol...@gmail.com on 21 Mar 2010 at 5:17

[GoogleCodeExporter]

I thought of saving the image as cover.jpg but realized that I maintain a 
directory 
of "Unsorted" mp3s. If I did that then all of the mp3s in this directory would 
share 
a common album label(it would find the cover.jpg in the unsorted directory and 
use 
it for all following MP3s in the folder)

Original comment by aaron.ri...@gmail.com on 21 Mar 2010 at 9:08

[GoogleCodeExporter]

See also 
http://www.tivocommunity.com/tivo-vb/showthread.php?p=7837076#post7837076

Original comment by ian.ol...@gmail.com on 21 Mar 2010 at 9:29

[GoogleCodeExporter]

Got this working, it updates the MP3 with the downloaded album art. 

The only problem I am having now is two of my mp3 files are ID3V1 not ID3V2. It 
would'nt matter if I updated the ID3V1 tag with album art since the 
getAlbumArtFromID3 only looks at V2 tags. 

We can either update getAlbumArtFromID3 to include the same functionality for 
ID3V1
(that is if V1 allows us to store album art). If we cannot store album art in 
V1 
tags then we could explore the idea of replacing the ID3V1 data with ID3V2 but 
at 
first glance it doesnt look like this functionality of currently built into the 
blinkenlights id3 fetcher.

We could just let it go and be ok with harmonium fetching the album art for 
those 
MP3s with outdated tag data. This should be a minimal subset of the albums and 
I 
think it would be a better idea to let it go unless V1 tags can store album art.

The cache appears to be eliminated when the program is restarted so storing 
failed 
last.fm retrievals might not be useful since the request is only made on 
startup and 
only once per album. Unless there is some sort of permanent cache thats loaded 
from 
disk on startup.

Original comment by aaron.ri...@gmail.com on 21 Mar 2010 at 9:55

[GoogleCodeExporter]

Just saw the comment over at the tivo community forums. I agree that this 
should be 
a user configurable option. I didnt realize this would be a slow process...I 
have a 
2.89gb collection(fairly small) and it only takes about 5 seconds to retrieve 
the 
album art for about 25 albums. With the option to update ID3 tags with album 
art 
the "reboot" time the user is discussing would no longer be an issue as long as 
the 
very first time they loaded harmonium they loaded it with the understanding 
that 
they would have to give the system time to download album art. Future restarts 
would 
no need to fetch images from http.

Original comment by aaron.ri...@gmail.com on 21 Mar 2010 at 9:59

[GoogleCodeExporter]

Original comment by ian.ol...@gmail.com on 22 Mar 2010 at 1:46

• Added labels: Milestone-Release0.8

[GoogleCodeExporter]

Ok, I committed a version that modifies the mp3files embedded ID3 tag. This 
version 
also adds the ability to turn on/off the http album art.

I did run into one anomoly that I have not quite figured out how to fix. When a 
track is added to an album (such as during the build) the system will first see 
if 
the album has AlbumArt. If it does it wont ask the MP3 file for the 
information. 
This leads to two anomolies:

1.) When http download(or any other method) fails at retrieving album art the 
software will continue to look for album art for all the following added 
tracks. 
This is why it slows down when looking for album art on last.fm and cannot find 
it. 
Basically for directories of MP3 files without album art the software will 
check 
once per mp3 file.

2.) When the request is made on the first mp3 and it succeeds the album is 
updated 
to reflect that MP3file as the "ArtSource". This works great when navigating 
through 
the browse windows because it has a cached album cover linked to the album. BUT 
the 
album art doesnt appear to be directly connected to the music object itself. 
Whenever a song is played the request for album art is repeated. This is 
unneccessary. If the song is a member of an album it should simply use the 
albums 
artsource as the album art. I tried to fix this but I got a headache trying to 
trace 
down where to do this via the createManagedImage function. 

For #2 I know that the MP3File class is being used as I receive debug 
statements 
reflecting calls to hasAlbumArt when changing songs. Perhaps the answer here is 
to 
add an ArtSource attribute to the MP3File class. We would also need a 
setAlbumArt 
option so that when a track is being added to an existing album that already 
has 
album art it can update the album art for that MP3File with the album art it 
already 
has. Then the getAlbumArt function would simply check to see if the art source 
exists in the class attribute before attempting to retrieve a new one.

Original comment by aaron.ri...@gmail.com on 23 Mar 2010 at 3:18

[GoogleCodeExporter]

Ok, I realized what is going on here. When the Album labels something as the 
ArtSource all it is really saying is to invoke the getAlbumArt of that item to 
retrieve the album art. So, whenever an image is displayed the album art is 
retrieved from one of the 3 sources(ID3, File, HTTP). Since the program now 
updates 
ID3 tags it doesnt have to do HTTP on the MP3Files it has updated, it just gets 
the 
information from the ID3 tag. Any MP3s not yet played and who dont have 
embedded 
album art go out to http and download the album art and save it to the ID3 tag. 

It almost seems as though to minimize http requests we either need to update 
all the 
MP3File ID3 tags OR change the way the now playing screen references album art 
so 
that it always uses the ArtSource designated in the album(track 3 uses track 
1's 
album art)

Original comment by aaron.ri...@gmail.com on 23 Mar 2010 at 3:57

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

So, I think I have a better idea for album art. I think we should add an album 
art 
cache of sorts. I realized today that changing the ID3 tags is useful, but in 
reality it can cause major problems down the road. What if the album art that 
is 
retrieved is low-quality? The person would have to somehow figure out what 
albums/mp3 files have been updated by harmonium and use a tool to remove the 
album 
art. Here is my new idea:

A album art cache. Harmonium would create a folder called ".harmonium" within 
that 
folder would be the following:

.HarmoniumCache    -    Existing file
imageCache         -    Folder

Within the albumArt folder we would create a directory for each artist in the 
MusicCollection whose album art was not found through ID3 or File The directory 
structure would be as follows:
 <Music Folder>/.harmonium/imageCache/albumArt/

Within that folder would be one file per album per artist with the following 
naming 
convention:
<Artist>-<Album>.jpg

adding this cache directory also opens up the possibility of a 
<Music Folder>/.harmonium/imageCache/artistArt/ directory where artist images 
could 
be stored. 

The huge benefit this offers is it incurs very low overhead to add. Basically, 
the 
HTTP request function would create the image and subsequent calls to the 
getAlbumArt 
function would first check for the existance of the file with that structure. 
Since 
the music folder can be requested from the prefs object we wouldnt need to mess 
with 
anything, not even the now playing screen.

It also gives us a solid foundation for future items we may want to cache as 
well as 
offering the option for users to retrieve new album art from last.fm or change 
a 
specific titles album art themselves by just replacing the .jpg with a 
different one.

Original comment by aaron.ri...@gmail.com on 24 Mar 2010 at 1:03

[GoogleCodeExporter]

If you sign off on my previous statement ian then this is practically done. I 
have 
it now so it saves the album art to the file cache, it checks the file cache 
before 
it goes to HTTP. Again, here are the benefits of going this route:

1.) Album Art is downloaded from an online service and stored to prevent future 
requests
2.) Album Art can easily be removed for recreation.
3.) Once album art is saved for an album no future tracks tied to that album 
will 
need to download cover art(since each track will look for the same filename it 
will 
find the first one created).
4.) Adds .harmonium cache folder to be used for other harmonium specific 
caches, 
such as Artist Art.
5.) Does not modify MP3 files which seems a whole heck of alot safer.

Original comment by aaron.ri...@gmail.com on 24 Mar 2010 at 2:51

[GoogleCodeExporter]

Thanks Aaron, this sounds really good!

Original comment by ian.ol...@gmail.com on 24 Mar 2010 at 2:03

• Added labels: Priority-Hopefully
• Removed labels: Priority-Maybe

[GoogleCodeExporter]

Done. I uploaded the latest version. I commented out the ID3 tag update. I 
think we 
should consider canning ID3 update due to the potential for destruction. I 
didnt 
completely remove the code however incase we decide to leave the functionality 
in 
there and add an option to enable it(disabled by default)

Original comment by aaron.ri...@gmail.com on 24 Mar 2010 at 5:23