i was allso having the same problem

I'd just like to chime in to say that I was having the exact same problem and the solution seemed to work for me too.

I second a request for a dev to look into the cache technique used.

I have the same problem. Okay, disabling caching "fixes" it, but I think that is not the best solution. Is the caching algorithm somehow broken? Is it going to be fixed soon? This problem is quite annyoing.

Like rovingcowboy said, it is in different locations depending on the OS. But it is not the MediaMonkey.ini that is found in your Program Files folder. It is the Local MediaMonkey.ini

Mediamonkey.ini default file locations:
Windows XP: C:\Documents and Settings\<USERNAME>\Local Settings\Application Data\MediaMonkey
Windows Vista and Windows 7: C:\Users\<USERNAME>\AppData\Local\Mediamonkey

Where is MediaMonkey.ini file wrote:This album art has been driving me nutz too. Where co I find the ini file?
Thanks

depends on your op system.
it is in different locations on them, so do a search for mediamonkey.ini and make sure you search for hidden files.
because it is a hidden file.

This album art has been driving me nutz too. Where co I find the ini file?
Thanks

Pete10 wrote:I noticed a setting in the local MediaMonkey.ini file:
DontUseCoversCache=0
Maybe setting this to 1 would help (also slowing down the display perhaps)?

Thanks a million for that! That Album Art bug was driving me crazy! Glad to finally be able to enjoy all the work done tagging my library.

Thanks for the explanation.
I think I would rather sacrifice a few hundred MB of hard drive space to have it show album art faster. So I believe I will leave the cache on for now.

the album art cache was put there for faster showing of the album art in the album art with details view.

but in using it monkey was making copys of your album art to put in that cache. so you if keeping your art in different folder from your music were ending up with duppies of your album art and taking up your hd space.
so they gave us control over the cache by telling us were to turn it off. but i have not see that line in the ini file as of late so they must have changed it again.?

but not using it just saved room on your system and took longer to show the covers in the album art with details view.



thought this was the same post about this as before. i just read it and found pete10 said he did see the line in the ini file so its still there which is good.

I wonder what the disadvantage is to not using the MM cache? I imagine it is there for a reason.
Can any Devs chime in?

Glad it worked! I suppose the developers should have a look at their caching implementation. I didn't notice a significant lag with the new settings either. In general, perhaps it is better to let the OS do the caching rather than implement it per program.

Pete10 wrote:I noticed a setting in the local MediaMonkey.ini file:
DontUseCoversCache=0
Maybe setting this to 1 would help (also slowing down the display perhaps)?

You da man! This seems to have resolved the issue. Since changing the setting I've had a little weirdness of a different kind (an album I updated wouldn't display album art in the album art window, though I could see it in the properties dialog) but no full-scale dropping of album art like before. I can't tell you how much more pleasant this makes browsing my albums.

i'll try it! thanks!

I noticed a setting in the local MediaMonkey.ini file:
DontUseCoversCache=0
Maybe setting this to 1 would help (also slowing down the display perhaps)?