dbdog wrote:

PetrCBR wrote:Covers tbumbs are stored in memory because of speed. For next 3.1 beta (build 1202) i've made some changes so it should be more memory friendly (about 1/3 less memory usage in AA view).

Thanks so much for the reply. By the sounds of your reply, what I'm experiencing may be normal for this version of MM. It's trying to store about 7500 thumbs in memory and that's gotta eat alot of memory. It seems like it is both caching art in temp folders and also storing them in RAM. Correct?

I'm also thrilled that it's something that will be addressed in v3.1. I'll look into getting myself on a list to be allowed to get the beta when it is available. I suppose I might be a decent tester.

Cheers,
dbdog

The beta is already available. 1202 is the latest available build for testing (many of us are already testing 3.1): http://www.mediamonkey.com/forum/viewto ... 22#p179100

PetrCBR wrote:Covers tbumbs are stored in memory because of speed. For next 3.1 beta (build 1202) i've made some changes so it should be more memory friendly (about 1/3 less memory usage in AA view).

Thanks so much for the reply. By the sounds of your reply, what I'm experiencing may be normal for this version of MM. It's trying to store about 7500 thumbs in memory and that's gotta eat alot of memory. It seems like it is both caching art in temp folders and also storing them in RAM. Correct?

I'm also thrilled that it's something that will be addressed in v3.1. I'll look into getting myself on a list to be allowed to get the beta when it is available. I suppose I might be a decent tester.

Cheers,
dbdog

Covers tbumbs are stored in memory because of speed. For next 3.1 beta (build 1202) i've made some changes so it should be more memory friendly (about 1/3 less memory usage in AA view).

yes when they first started the cacheing some did say it was loading lots of ram, but i think they got that fixed. since mm 3.0.0 was out.

i have changed some settings in my system and now instead of loading the mouse drivers in real time, they load in normal priority, but with any program i use including notepad the mouse drivers are lagging making it look like the computer is lacking in ram, so there is some app. that windows is running that is causing troubles with the mouse and other things as to what that app is i don't know. but if having trouble with the mouse i am to try turnning down the hardware acceleration or turn it off, those seem to work a little but not worth the effort for me to reduce the useability of the other programs, but maybe that will help on yours too.

if not you can always right click on the task bar and click on the taskmanager and then find mediamonkey in the process tab, right click on it then click on set priority, and click on real time.
that will speed up mediamonkey and all its background services, then he might get done with what ever is making him keep the images in ram ?
it could just be he is waiting on some other app that has more priority then him, and that other app, is hanging.

there was a lot of updates yesturday from microsoft's windows update site, get them and see if it fix'es the issue?

don't worry about changing that priority for monkey like that, its just for the current session, and will go back to normal for the next session so you have to do that all the time, unless you get the priority program that starts all the programs in high priority. when you start them after you start the priority program.
that might help too.

but again they are just patches,

nohitter151 wrote:It's just cache-ing the artwork to your hard drive for future, quick access. You can even check where it is in the temp folder:

C:\Users\USERNAME\AppData\Local\Temp\MM_Cache on Vista

and probably something like

C:\Documents and Settings\USERNAME\Local Settings\Application Data\Temp\MM_Cache on XP

Have you tried just letting MM do its thing until its done? Maybe the cpu access will go down once MM is finished.

Hey Nohitter151,

Indeed it does seem to be caching to my temp folder. You are correct. So I'm wondering why over 500MB of RAM is needed to run MM with the "show album art with details" selected. When it is running with so much RAM use, my computer grinds to a halt. Is it also holding the bmp's in my RAM? When I navigate away from this view it drops to about 80MB and my computer begins to respond again.

I've set my memory to prefer programs and have set the virtual memory maximums to the max (4096MB) for my system/program drive (C:) and both my music drives. And still not better performance. Grinds to a halt!

Cheers
dbdog

Lowlander wrote:2) I don't know if it's a MediaMonkey bug or that something specific on your machine is causing this issue.

I'm surprised that others haven't commented on whether or not they experience the same behavior. There must be many out there with large libraries with tons of jpg cover artwork stored in folders. Or is everyone else embedding artwork in the tags?

1) Haven't seen others report it here
3) Caching is actually desirable as it reduces the resources MediaMonkey requires when loading album art

2) I don't know if it's a MediaMonkey bug or that something specific on your machine is causing this issue.

It's just cache-ing the artwork to your hard drive for future, quick access. You can even check where it is in the temp folder:

C:\Users\USERNAME\AppData\Local\Temp\MM_Cache on Vista

and probably something like

C:\Documents and Settings\USERNAME\Local Settings\Application Data\Temp\MM_Cache on XP

Have you tried just letting MM do its thing until its done? Maybe the cpu access will go down once MM is finished.

Lowlander wrote:You can change your virtual memory settings within Windows itself (System Properties > Advanced > (Performance) Settings > Advanced > (Virtual Memory) Change and now you have the window where per hard drive you can set the virtual memory). You can set up various on various discs or just one on any disc. I believe the general rule is to add no more than 1.5 times the physical memory as virtual memory. Besides you're seemingly experiencing a memory leak issue, which means that adding virtual memory might do no good in this case.

Thanks Lowlander. I see the control panel you are referring to. I'm still not sure if its a leak that will continue to eat RAM forever or if it will stop when all my art is in the cache. It would be an interesting experiment to try if I could add enough RAM to see if it stops. However I still think that there's got to be a better solution than allowing MediaMonkey to cache all my artwork.

I still haven't heard from any of the staff about:
1. whether or not it's just me that is experiencing this huge memory load
2. is this is a bug, or
3. if it was actually designed to cache all the artwork.

Cheers
dbdog

You can change your virtual memory settings within Windows itself (System Properties > Advanced > (Performance) Settings > Advanced > (Virtual Memory) Change and now you have the window where per hard drive you can set the virtual memory). You can set up various on various discs or just one on any disc. I believe the general rule is to add no more than 1.5 times the physical memory as virtual memory. Besides you're seemingly experiencing a memory leak issue, which means that adding virtual memory might do no good in this case.

Thanks for the suggestion. Increasing my virtual memory might be a good workaround. I'm still hoping for a fix rather than a workaround so I'm hoping that the staff will respond to my log and ticket. I've asked Peke to let me know where to send my log file.

If I need to increase my virtual memory, I have a copy of WinXPManager installed and it has a virtual memory optimizer so I might play around with it. I doubt if it will let me change it's location to another disc though. I've never tried that.

Thanks again,
Dave

you don't seem dumb about computers so short and fast.

increase your quantums for the programs.
change your page file from the drive that the program is on to any other one
that is fast and has at least 20 gb's of space you can use.
that will get the swap file off the drive the program is using and might help?
if you can also make the page file bigger, the more hd space you have the more swap file you need.
you can let windows controll it but that makes it keep making it bigger and smaller. if you set it,
then set it for about 1000 mb's of space for every 20 gbs of hd space. that might seem a little big but
it might just make it work again for you since you have all those images loading in ram,

also there was a program that was free but you got to buy it now from IObit, it had a smart ram program in it that was good at making the swap file bigger with out really needing you to do all the settings. they changed the name of the program it use to be advanced system care, found on http://www.majorgeeks.com but don't just use it willy nilly if you get that program double check what it wants to do when you optimize your system with it.
or it will shut of services you need.
but getting it and using the added in bonus program for smart ram, won't mess with the system just the ram.
when i used it i found it ran my page file all the way up to over 3 gb's and i only had it set at 2000 mb's and my system ran just fine, i never noticed any slow downs.

but still that is only putting a patch on the error, and not getting the code fixed. but still if you can't wait for the code to be fixed then the patch might be for you.?

Hey there,

Thanks for the chatter. Yes, all my art is in jpg format. While some are big (if they are in files to be printed and I haven't bothered to scale them down for onscreen res) the vast majority are under 1mb and about 60% are under 100k. I have about 2GB of artwork in about 8000 jpg files. Some folders have multiple jpgs for back and inside pages etc. Still, why is MM trying to load all my artwork into RAM. Seems bizarre.

I reset my DontUseCoversCache=0 and the problem is still the same. The images all load in about 10 minutes but by then 1GB of ram is eaten and my machine is hurtin'.

Here' a snippet of my log that shows artwork being loaded over and over:
.......
00001151 75.77846527 [3736] MP3.ReadHeader H:\Music\Artist-A\Art Tatum\Art Tatum [1956] - The Tatum Group Masterpieces, Vol. 8 [mp3]\01-Art Tatum-Gone With The Wind.mp3
00001152 75.78501129 [3736] MP3.ReadHeader - File size 7777997
00001153 75.79108429 [3736] MP3.ReadHeader - Found ID3v2, length: 2322
00001154 75.79722595 [3736] MP3.ReadHeader framestarts: 2332, 2332
00001155 75.80358124 [3736] MP3.ReadHeader finished
00001156 75.81055450 [3736] MP3: Going to read tag from H:\Music\Artist-A\Art Tatum\Art Tatum [1956] - The Tatum Group Masterpieces, Vol. 8 [mp3]\01-Art Tatum-Gone With The Wind.mp3
00001157 75.81729126 [3736] MP3: Tag read from H:\Music\Artist-A\Art Tatum\Art Tatum [1956] - The Tatum Group Masterpieces, Vol. 8 [mp3]\01-Art Tatum-Gone With The Wind.mp3
00001158 75.82431030 [3736] 4072 DB open SQL: SELECT Songs.* FROM Songs WHERE Songs.IDMedia=? AND Songs.SongPath=?
00001159 75.83066559 [3736] 4072 DB lock finished, took 2206335.
00001160 75.83695221 [3736] GetFileInfo: Found in DB
00001161 75.84366608 [3736] 4072 DB open SQL: SELECT * FROM Covers WHERE IDSong=10824 ORDER BY CoverOrder
00001162 75.85084534 [3736] 4072 DB lock finished, took 2010510.
00001163 75.85740662 [3736] Added Covers: 40
00001164 75.86354828 [3736] Remaining Covers: 39
00001165 75.87026978 [3736] Remaining Cover Lists: 21
00001166 75.88066864 [3736] Added Cover Lists: 22
00001167 75.88071442 [3736] Added Covers: 40
00001168 75.88076782 [3736] Remaining Covers: 39
00001169 75.88080597 [3736] Remaining Cover Lists: 21
00001170 75.90122986 [3736] Added Cover Lists: 22
00001171 75.90137482 [3736] 4072 DB open SQL: SELECT Covers.* FROM Covers, Songs WHERE songs.idalbum=? AND covers.idsong=songs.id ORDER BY Covers.idsong
00001172 75.92465210 [3736] 4072 DB lock finished, took 69362618.
00001173 75.92470551 [3736] Added Covers: 40
00001174 75.98833466 [3736] GetFileInfo: H:\Music\Artist-F\Fats Domino\Fats Domino [1956] - This Is Fats [mp3]\13-Fats Domino-Blueberry Hill.mp3
00001175 75.98838043 [3736] GetFileInfo: readPictures=spAlways
00001176 75.98842621 [3736] GetFileInfo: H:\Music\Artist-F\Fats Domino\Fats Domino [1956] - This Is Fats [mp3]\13-Fats Domino-Blueberry Hill.mp3
00001177 75.98867798 [3736] Added Cover Lists: 23
00001178 75.98902130 [3736] MP3.ReadHeader H:\Music\Artist-F\Fats Domino\Fats Domino [1956] - This Is Fats [mp3]\13-Fats Domino-Blueberry Hill.mp3
00001179 75.98908234 [3736] MP3.ReadHeader - File size 4525132
00001180 75.98914337 [3736] MP3.ReadHeader - Found ID3v2, length: 3469
00001181 75.98918915 [3736] MP3.ReadHeader framestarts: 3479, 3479
00001182 75.98923492 [3736] MP3.ReadHeader CheckMoreHeaders started
00001183 75.98928070 [3736] MP3.ReadHeader CheckMoreHeaders Endtest: 6551
00001184 75.98932648 [3736] MP3.ReadHeader CheckMoreHeaders finished
00001185 75.99812317 [3736] MP3.ReadHeader finished
00001186 75.99821472 [3736] MP3: Going to read tag from H:\Music\Artist-F\Fats Domino\Fats Domino [1956] - This Is Fats [mp3]\13-Fats Domino-Blueberry Hill.mp3
00001187 76.00611115 [3736] MP3: Tag read from H:\Music\Artist-F\Fats Domino\Fats Domino [1956] - This Is Fats [mp3]\13-Fats Domino-Blueberry Hill.mp3
00001188 76.00620270 [3736] 4072 DB open SQL: SELECT Songs.* FROM Songs WHERE Songs.IDMedia=? AND Songs.SongPath=?
00001189 76.00659180 [3736] 4072 DB lock finished, took 1010595.
00001190 76.00678253 [3736] GetFileInfo: Found in DB
.......
and so on forever

Cheers and thanks again for your help.
dbdog

even so nohitter151, thats a lot of ram for artwork to take up. ? unless the images are in-fact saved as tiff files. or some other huge size. then those will eat up ram like theres not enough in the world. but i thought i seen them say the image's were all .jpg files. unless they are saved at a size larger then 500 x 500 and 600 dpi then that should not matter. but if they are 1200 x 1200 by 1200 dpi then that is the reason there. and if they are tiff. files that size, why, why, just go out and get a 9 course dinner and come back after you eat, the images might be showing then.

dbdog wrote:

the above is because monkey is set to defaultly convert the album art to small bmp thumbnails to use for the album art view and save them in a cache. you can go in to the ini file for monkey and turn that off if you want too.
just change the number 1 to zero in the proper line.

Thanks so much for your help. This sounds like my issue. Can you help me identify the correct line in the ini file please? I see one that looks likely but it is already set to 0:

DontUseCoversCache=0

Cheers
dbdog

FYI: The covers cache is simply .bmp files resized and extracted to a temporary folder on your hard drive so that the covers can be loaded much more quickly into the album art views. By using DontUseCoversCache=1, you're telling MM not to save the extracted covers to your temporary folder, which means the art has to be resized dynamically in the computer memory every time you open the art view. You should expect much higher memory usage with this setting, not lower. Seems that is the opposite of the effect you're trying to get.