"Missing" covers download always re-download the full covers (only the full one) already on SD

[GoogleCodeExporter]

What steps will reproduce the problem?
Always when I select download covers, the loader always try to download the
full covers already downloaded ie. for "Wii Sports Resort": I go to RIGHT
for download "missing" covers, he find 2d and 3d covers on SD, and DONT
download from network, he don't find the disc cover and try to download it
without success, and next he download the full cover (also if it's already
on SD). When finished, also if I re-choice download cover pressing RIGHT on
wiimote ("download only missing covers") he re-download the full cover,
also if he've downloaded a minute ago.
This happens with ALL full covers, or at least with the majority.
When I try to download missing covers of all games, I've to wait about 2
hours (!) because he re-download all full covers.

What is the expected output? What do you see instead?
I expect he don't try to redownload a file he've already downloaded, if
I've selected "download only *MISSING* covers".

What version of the loader are you using?
The last one loaded on 222 (Hermes v4), the 57b4-222 version. But I've this
problem by the time I've included the full covers.

What is your System Menu version (e.g. 4.2u)?
3.2E, but it's a 4.2E downgraded (obviously it was an old model)

What is your media type (HDD, USB Flash, SD/SDHC)?
An USB HD Western Digital MyBook Essential 2TB

How is your media formatted (wbfs, fat32, ntfs)?
Mainly one NTFS partition for the wii games and some other minor partitions
(a FAT32 for apps and another 2 NTFS -not used by the wii- for data)

Which cios are you using and which version (222, 249v??)?
IOS36 re-truchasigned
cIOS249 Waninkoko r19 (based on IOS57)
cIOS250 Waninkoko r19 (based on IOS38)
cIOS222 Hermes r4 (IOS38 merged with IOS37)
cIOS223 Hermes r4 (IOS38 merged with IOS60)
cIOS202 USB2.0 (IOS60 merged with IOS36)
Homebrew channel based on IOS61

Please provide any additional information below.
I've a lot of things on wishlist on my favourite usb loader :D
1) Some games with A LOT of cheats (like SSBB) don't load it. But I've seen
this is already on this issues board.
2) It would be appreciated a "download "all" (and "missing") cheat codes"
like "download all/missing covers" feature with a click for all the games.
3) Same for "download all (missing) themes".
4) (not urgent) Download and using the themes on usb device instead of the sd.
5) "Restart" feature (in game, not in the loader) back to the loader
itself, instead of backing to (in my case) the BootMii ('cause as I seen
"restart" reboot the entire Wii, backing to the BootMii as I would power on)
6) (I know it's difficult, but it's a wish, not a "hey you must"... I hate
people pretending something, and I know it's annoying for you programmer.
Mine it's only a wish, please understand :D) A "Gamecube-mode" implemented
via software (like an "emulator") allowing using USB device in configurable
usb loader also for Gamecube games

I'll attach my config.txt, if you want to see this bug in action.

Sorry if my English isn't so good, I hope you've understanded. I use only
your loader 'cause it's the best one and I love it. :D

Best wishes,
Massi

Original issue reported on code.google.com by massi.ca...@gmail.com on 24 May 2010 at 12:02

Attachments:

• config.txt

[GoogleCodeExporter]

Update: the problem of full covers isn't for all games, but with the majority 
of them
(ie: Wii Sports Resort PAL)

Original comment by massi.ca...@gmail.com on 27 May 2010 at 2:50

[GoogleCodeExporter]

*NOT* fixed on 57b6... :(

Original comment by massi.ca...@gmail.com on 8 Jun 2010 at 10:52

[GoogleCodeExporter]

*NOT* fixed on 57b7

Original comment by massi.ca...@gmail.com on 17 Jun 2010 at 10:58

[GoogleCodeExporter]

When a full cover is added in HQ (1024x680), this problem occurs.
The covers are displayed OK.
When autodownloading covers, all 1024x680 covers are downloaded again.
A workaround is downsizing the HQ full covers from 1024x680 to 512x340.
Then they are detected as valid covers and not re-downloaded.

Original comment by TomBruun...@gmail.com on 21 Jun 2010 at 4:45

[GoogleCodeExporter]

I have tried it on v60 and cannot reproduce the problem.
Also tried with a HQ covers and it does not re-download it.
Can you re-try with v60 or v61b4 and report back if it still happens?

Original comment by ogg...@gmail.com on 21 Nov 2010 at 3:19

[GoogleCodeExporter]

I still have the problem on v61. For example, the cover

 http://www.wiiboxart.com/artwork/coverfullHQ/SZ5E5G.png

is redownloaded every time I update covers.

Original comment by TomBruun...@gmail.com on 7 Dec 2010 at 5:18

[GoogleCodeExporter]

Hi oggzee, I can see the problem also in 62a2-222.
I'll attach an example of cover ALWAYS redownloaded: HQ version of full cover 
of "Alone in the Dark" PAL (RRKP70), but the list of these covers always 
redownloaded is VERY long.
The original download link is
http://wiitdb.com/wiitdb/artwork/coverfullHQ/EN/RRKP70.png
I'll attach also a cover NOT always redownloaded, recognised correctly: Fatal 
Frame 4 Italian Patch (WFFF4I), original download link
http://wiitdb.com/wiitdb/artwork/coverfullHQ/EN/WFFF4I.png

The resolution for the two files is the same (1024x680, also if I've some full 
HQ covers 1024x681).
The RRKP70 (always redownloaded) is 299x299 dpi, 24-bit, but WFFF4I (always NOT 
redownloaded) is 96x96 dpi, 32-bit.
Maybe these difference can make the problem.

I hope this can help you fixing this bug.
Thanks,
Massi

Original comment by massi.ca...@gmail.com on 11 Dec 2010 at 4:11

Attachments:

• RRKP70.png
• WFFF4I.png

[GoogleCodeExporter]

Happy new year... Any news on this issue?

Original comment by massi.ca...@gmail.com on 1 Jan 2011 at 1:26

[GoogleCodeExporter]

same issue here on 62a-222

Original comment by Andrew.D...@gmail.com on 2 Jan 2011 at 9:04

[GoogleCodeExporter]

Same on 63b2-222...

Original comment by massi.ca...@gmail.com on 2 Jan 2011 at 10:25

[GoogleCodeExporter]

Same on 63-222 final...

Original comment by massi.ca...@gmail.com on 11 Jan 2011 at 2:39

[GoogleCodeExporter]

Should be fixed with v64a, please confirm.

Original comment by ogg...@gmail.com on 12 Jan 2011 at 10:41

• Changed state: Started

[GoogleCodeExporter]

I've fastly verified, apparently this problem is fixed on 64a :-) Thanks very 
much.

Original comment by massi.ca...@gmail.com on 12 Jan 2011 at 10:53

[GoogleCodeExporter]

Great!

Original comment by ogg...@gmail.com on 12 Jan 2011 at 12:13

• Changed state: Fixed

[GoogleCodeExporter]

I can verify that this issue is fixed in v64a thanks (:

Original comment by Andrew.D...@gmail.com on 12 Jan 2011 at 7:10