Windows cover fetching problems

[GoogleCodeExporter]

What steps will reproduce the problem?
1. For albums, tries to find cover.jpg/png and last.fm. that's all.
2. For library, directly fetching from last.fm. it doesn't care about 
artist.jpg/png in that folder.
3. These are quite different from README image loading order.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?

Please provide any additional information below.

Algorithm should be more sophisticated as in README.
Linux is OK! 

Original issue reported on code.google.com by parkm...@gmail.com on 4 Sep 2012 at 10:31

Attachments:

• cantata_albums.log
• cantata_library.log

[GoogleCodeExporter]

(Test/01-psy-blue_frog_(feat_g-dragon).flac ALBUM) GET IMAGE 
Test/01-psy-blue_frog_(feat_g-dragon).flac
(Test/01-psy-blue_frog_(feat_g-dragon).flac ALBUM) ATTEMPT TO READ IMAGE FROM 
CACHE
(Test/01-psy-blue_frog_(feat_g-dragon).flac) DOWNLOAD COVER
(Test/01-psy-blue_frog_(feat_g-dragon).flac ALBUM) TRY http: 
http://192.168.12.83/Test/cover.jpg
(Test/01-psy-blue_frog_(feat_g-dragon).flac ALBUM) CREATE HTTP JOB 64708376
GOT RESPONSE FOR JOB 64708376
(Test/01-psy-blue_frog_(feat_g-dragon).flac ALBUM) REPLY 203 DATA:0 TYPE:JPG
(Test/01-psy-blue_frog_(feat_g-dragon).flac ALBUM) GOT NUL FOR JPG, TRY PNG
(Test/01-psy-blue_frog_(feat_g-dragon).flac ALBUM) TRY http: 
http://192.168.12.83/Test/cover.png
(Test/01-psy-blue_frog_(feat_g-dragon).flac ALBUM) CREATE HTTP JOB 108578800
GOT RESPONSE FOR JOB 108578800
(Test/01-psy-blue_frog_(feat_g-dragon).flac ALBUM) REPLY 203 DATA:0 TYPE:PNG
(Test/01-psy-blue_frog_(feat_g-dragon).flac ALBUM) OK, TRIED ALL HTTP NEED TO 
DO LAST.FM
(Test/01-psy-blue_frog_(feat_g-dragon).flac ALBUM) TRY last.fm
(Test/01-psy-blue_frog_(feat_g-dragon).flac ALBUM) CREATE LAST.FM JOB 108578656
FAILED JOB 108578656
(Test/01-psy-blue_frog_(feat_g-dragon).flac ALBUM) LAST.FM FAILURE

(Test/01-psy-blue_frog_(feat_g-dragon).flac ARTIST) GET IMAGE 
Test/01-psy-blue_frog_(feat_g-dragon).flac
(Test/01-psy-blue_frog_(feat_g-dragon).flac) DOWNLOAD COVER
(Test/01-psy-blue_frog_(feat_g-dragon).flac ARTIST) TRY last.fm
(Test/01-psy-blue_frog_(feat_g-dragon).flac ARTIST) CREATE LAST.FM JOB 64433768
INFO JOB 64433768
(Test/01-psy-blue_frog_(feat_g-dragon).flac ARTIST) GOT LAST.FM REPSONSE:<?xml 
version="1.0" encoding="utf-8"?>
<lfm status="ok">
<artist>
  <name>artist_test</name>
          <mbid></mbid>
        <url>http://www.last.fm/music/artist_test</url>
  <image size="small"></image>
  <image size="medium"></image>
  <image size="large"></image>
  <image size="extralarge"></image>
  <image size="mega"></image>
  <streamable>0</streamable>
  <stats>
    <listeners>0</listeners>
    <playcount>0</playcount>
      </stats>

  <similar>
      </similar>
    <tags>
      </tags>
      <bio>
    <published></published>
    <summary></summary>
    <content></content>
  </bio>
  </artist></lfm>

(Test/01-psy-blue_frog_(feat_g-dragon).flac ARTIST) READ URL:

Original comment by parkm...@gmail.com on 4 Sep 2012 at 10:31

[GoogleCodeExporter]

The above comment from test4 should be incorrect.
However artist.jpg/png does not show in the 0.8.3 version.
Please give me the latest debug exe file if possible.

Original comment by parkm...@gmail.com on 4 Sep 2012 at 10:44

[GoogleCodeExporter]

${albumArtist}.jpg not show, either.

Original comment by parkm...@gmail.com on 4 Sep 2012 at 10:54

[GoogleCodeExporter]

No. The README is CORRECT. It stares:

"if MPD folder exists, is not specified as a http URL, and is readable, then
   cantata will look for the following within the folder containing the song"

Therefore, the following list of filenames ARE NOT searched for http:// MPD 
paths.  ONLY cover.jpg/cover.png will be attempted via HTTP - NOTHING else. 
This matches the behaviour of MPDroid, and works fine for me. Attempting to 
fetch the others via HTTP would be too slow.

Original comment by craig.p....@gmail.com on 4 Sep 2012 at 11:19

• Changed state: Invalid

[GoogleCodeExporter]

OK and I'll try as you pointed out.
However it's a pity that you abandoned very good option even though it's not 
that difficult to make it happen!
It could have been a very good feature for many audiophiles.

Original comment by parkm...@gmail.com on 4 Sep 2012 at 2:57