I think this temp folder for thumbnails is less than ideal. Thousands of bmp files will spread all over the hard disk in noncontiguous clusters, quickly leading to heavy disk fragmentation on a folder MM needs to access instantly while browsing albums with AlbumArts ON. Each file will use as many as 20 clusters (NTFS default 4k). Defragmenting this folder alone, as it grows in the 1000's of files file take forever and windows will quickly fail to provide the service MM needs when browsing album arts. This is just how NTFS was designed and thumbnails management just fails to meet this design.
These are things that I tried on my system. I found the improvement to be quite spectacular.
* temp folder
- move this folder away from system drive if you have one spare. Either update MM options (general) or make a junction point. If you deal with RAMDISKS, this might be a very good candidate for performance improvements.
- When possible, move this folder to a drive with larger cluster size. 4k leads to like 15-20 clusters per bmp. 64k clusters are nice for audio files and will allow most thumbnail files to fit into a single cluster. Compared to 15-20, you can figure how many seeks and accesses the drive will be spared. Bottom line, I believe the cache folder belongs on the audio drive when you have one.
- In case you don't have a dedicated audio drive and have enough cpu power, enabling ntfs compression on the cache folder might reduce stress on the hard disk and prevent some fragmentation as well, at reasonable cpu-time cost.
- In case your hard disk was not defragged recently, move the temp folder to another disk/usb key. This small folder will most likely be heavily fragmented and lengthen the needed defragmentation process for nothing. Put it back where it was afterwards.
- Use sysinternal contig tool on a regular basis afterwards. Point it at the temp folder and let it make files contiguous. If your disk controller / OS combo handles NCQ, thumbnails access should be blazing fast from then on.
- As deleting the old folder will create heavily fragmented free space, make sure to use a defrag tool that consolidates free space, to prevent new files from being just as fragmented as before. As we can see, MM creating all these tiny files and spreading them all over the hard disk definitely has an impact on overall system health and performance. if you're not sure how to consolidate free space, just put the old folder in the recycle bin or rename it instead of deleting it (after you have a copy somewhere). Leave it there until the matter is resolved.
- Despite its name, this folder should not be seen at temporary and should not be deleted, unless you want MM to recreate every single thumbnail. I'd rather keep it in good shape, grow as large as it wants, even make backups of it. Then, I might have missed something; correct me as needed.
This is what I found on optimizing album arts. In my case, just moving the folder to a 64k clusters drive made a significant improvement. Large clusters will prevent file fragmentation in my case; I will try and keep files and subfolders in contiguous sectors.
As I was on the fragmentation matter, I made some tests with the MM4(beta) database file and found that fragmentation, again, was the one and only cause for sluggish browsing. Not a small thing to find. This is for a 330mB database, 100k+ entries, on a pretty decent system. Pointing contig to the db file showed 36 fragments. Moving the file to some contiguous area took less than one second and the change was so spectacular I couldn't believe it. Browsing went from plain sluggish to silk smooth. As MM constantly updates the DB file on disk, editing got quite smoother too.
My thoughts on the matter are that a db file fragmenting that much is just wrong. Maybe some sparsing should be implemented? Windows db servers admins usually deal with heavy db fragmentation when they know what they're doing. Since MM users are no admins, program design should probably be altered to deal with this. 4.x might be a good time for this.
In the meantime, give a try at sysinternal's contig (command line defragmentation tool), maybe along with "power defragmenter" which brings GUI to it and check your db file. Those in the 50.000+ entries might be in for some surprise.
While I am now satisfied with both album arts and browsing experience, I find quite stunning for the whole thing to be down to disk fragmentation.
As a side note on Album Arts, one remaining problem is that MM4 (which is beta) now crashes when being "asked too much"; namely, fast-browsing the 20000+ albums from the album root node, with album arts display ON. I wouldn't know if it would crash before I moved the folder, since AlbumArts browsing was so painful and always gave up.
In case you experience crashes in MM3 after removing the %userprofile% metacache folder, please report here.
For reference, my system is XP-sp3, i7-920, 4GB ram (3.
, dedicated audio drive w/64k clusters, mirrored raid for MM profile folder and dedicated system drive with 4k clusters.
Rojer.
I think this temp folder for thumbnails is less than ideal. Thousands of bmp files will spread all over the hard disk in noncontiguous clusters, quickly leading to heavy disk fragmentation on a folder MM needs to access instantly while browsing albums with AlbumArts ON. Each file will use as many as 20 clusters (NTFS default 4k). Defragmenting this folder alone, as it grows in the 1000's of files file take forever and windows will quickly fail to provide the service MM needs when browsing album arts. This is just how NTFS was designed and thumbnails management just fails to meet this design.
These are things that I tried on my system. I found the improvement to be quite spectacular.
* temp folder
- move this folder away from system drive if you have one spare. Either update MM options (general) or make a junction point. If you deal with RAMDISKS, this might be a very good candidate for performance improvements.
- When possible, move this folder to a drive with larger cluster size. 4k leads to like 15-20 clusters per bmp. 64k clusters are nice for audio files and will allow most thumbnail files to fit into a single cluster. Compared to 15-20, you can figure how many seeks and accesses the drive will be spared. Bottom line, I believe the cache folder belongs on the audio drive when you have one.
- In case you don't have a dedicated audio drive and have enough cpu power, enabling ntfs compression on the cache folder might reduce stress on the hard disk and prevent some fragmentation as well, at reasonable cpu-time cost.
- In case your hard disk was not defragged recently, move the temp folder to another disk/usb key. This small folder will most likely be heavily fragmented and lengthen the needed defragmentation process for nothing. Put it back where it was afterwards.
- Use sysinternal contig tool on a regular basis afterwards. Point it at the temp folder and let it make files contiguous. If your disk controller / OS combo handles NCQ, thumbnails access should be blazing fast from then on.
- As deleting the old folder will create heavily fragmented free space, make sure to use a defrag tool that consolidates free space, to prevent new files from being just as fragmented as before. As we can see, MM creating all these tiny files and spreading them all over the hard disk definitely has an impact on overall system health and performance. if you're not sure how to consolidate free space, just put the old folder in the recycle bin or rename it instead of deleting it (after you have a copy somewhere). Leave it there until the matter is resolved.
- Despite its name, this folder should not be seen at temporary and should not be deleted, unless you want MM to recreate every single thumbnail. I'd rather keep it in good shape, grow as large as it wants, even make backups of it. Then, I might have missed something; correct me as needed.
This is what I found on optimizing album arts. In my case, just moving the folder to a 64k clusters drive made a significant improvement. Large clusters will prevent file fragmentation in my case; I will try and keep files and subfolders in contiguous sectors.
As I was on the fragmentation matter, I made some tests with the MM4(beta) database file and found that fragmentation, again, was the one and only cause for sluggish browsing. Not a small thing to find. This is for a 330mB database, 100k+ entries, on a pretty decent system. Pointing contig to the db file showed 36 fragments. Moving the file to some contiguous area took less than one second and the change was so spectacular I couldn't believe it. Browsing went from plain sluggish to silk smooth. As MM constantly updates the DB file on disk, editing got quite smoother too.
My thoughts on the matter are that a db file fragmenting that much is just wrong. Maybe some sparsing should be implemented? Windows db servers admins usually deal with heavy db fragmentation when they know what they're doing. Since MM users are no admins, program design should probably be altered to deal with this. 4.x might be a good time for this.
In the meantime, give a try at sysinternal's contig (command line defragmentation tool), maybe along with "power defragmenter" which brings GUI to it and check your db file. Those in the 50.000+ entries might be in for some surprise.
While I am now satisfied with both album arts and browsing experience, I find quite stunning for the whole thing to be down to disk fragmentation.
As a side note on Album Arts, one remaining problem is that MM4 (which is beta) now crashes when being "asked too much"; namely, fast-browsing the 20000+ albums from the album root node, with album arts display ON. I wouldn't know if it would crash before I moved the folder, since AlbumArts browsing was so painful and always gave up.
In case you experience crashes in MM3 after removing the %userprofile% metacache folder, please report here.
For reference, my system is XP-sp3, i7-920, 4GB ram (3.8), dedicated audio drive w/64k clusters, mirrored raid for MM profile folder and dedicated system drive with 4k clusters.
Rojer.