Make album artwork show instantly [#6459]

[Livionium]

I completely agree here. It would be a hella lot easier to look through my music if the album art showed up instantly, or at least if all the album art in a list of music was loaded on the same time, not when I scroll over them.

This is actually one of the very few, but most annoying problems I have with MM.

[Dreadlau]

Personally, I find the delay of thumbnails loading in a real usability-killer for album view.

I totally agree.

+1000 I never use the cover view. And its because of the irritating delay!
Also I wonder why we can't have a cover view for the now playing list. :S ?

[Lowlander]

Probably be cause the Album Art view is more album based whereas the Now Playing is track based. Using Album Art view in the Now Playing wouldn't properly convey that only 1 or multiple tracks on an album are queued for playback.

[Lowlander]

Added to Mantis: http://www.ventismedia.com/mantis/view.php?id=6459

[Dreadlau]

Added to Mantis: http://www.ventismedia.com/mantis/view.php?id=6459

Thanx

[Rudderford]

I agree, this has actually turned out to be a dealbreaker for me before going gold. Currently it seems to stand between this and J River Media Center which has a superior GUI and INSTANT cover art when scrolling and resizing. This is not just for looks, it makes it much easier to find faulty and inconsistent covers and even tags in relation to covers. Like Media Monkey more feature wise though.

[Dreadlau]

If instant Cover Art scrolling and resizing is possible with J River. It must be possible with MM!

It's time the developpers make a serious effort about the GUI.
Most of the other media managers are ahead of MM in this area imo.

[Dreadlau]

now tracked at http://www.ventismedia.com/mantis/view.php?id=6591

Thank you for looking into this.

[Guest]

The link said it was fixed in build 1319, but this does not even exist for download! 1303 is the only current one. I've been annoyed with this for months! This is the main problem that keeps me from wanting to pay for Gold.

[Lowlander]

The link said it was fixed in build 1319, but this does not even exist for download!

The link also says it's fixed in version 4 of MediaMonkey and that's still in development.

[curtin1060]

Hi,
One thing to check/verify is that your Tools->Options->Temp directory isn't that huge ... I do Software Development myself so my Tmp dir is huge ... I was wondering why MM album covers loaded so slow .... I had a large amount of subdirectories and files in the Tmp dir, this will cause MM's reading of the cache to be very slow, because the filesystem has too much crud.

Not a MM developer, just a user and really liking it!

Thanks,

Craig

[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., dedicated audio drive w/64k clusters, mirrored raid for MM profile folder and dedicated system drive with 4k clusters.

Rojer.