Any news on this topic? It hasn't got any less annoying...

Let me say first that I completely understand and respect the hard work developers put in MediaMonkey and thank you for that.
However, a bug like this is elementary and inexcusable to be running for THIS long with so many paying customers complaining about it.

In any case, hoping to see this fixed soon.

Cheers.

I'd like to add my voice for quicker album scrolling too. It's frustrating when I've taken days to go through most of my collection and get everything tidied up for covers to have a significant delay in loading.

I understand the technical points made in the other post but many other apps seems to manage it OK - and I'm running a quad-core 3GHz Intel on Vista 64 bit... I'm surprised loading in a few bitmaps is such an arduous procedure.

As a recent licence purchaser I hope my £££ go towards (in my view necessary) usability tweaks like this, please

Thanks,
Dave

Actually, I brought this up while Beta testing in December of 2008:
http://www.mediamonkey.com/forum/viewto ... 50#p183263

In one beta build it appeared to be resolved, but later, it reverted back to the current operation. If you read through the thread, you'll see that Petr (developer) acknowledged that it had been changed in 3.1. I just wish there was a way to get the old functionality back.

I will, however, bring this up in next Beta testing run.
Thanks
BP

Cool, will do.
Thanks

wdpaynter wrote:An additional note (as if I didn't ramble enough already)

I have tried other similar programs to MM that have a similar layout/interface and the cache thingy works the way I would like and the way MM used to

I am not suggesting that MM is inferior or anything of the sort, rather that this is possible, and maybe it can be looked at

I agree with you completely. When beta testing begins for the next MM release, I urge you to test the new beta builds and report the issue if it persists. This is the best way to catch the developers attention.

An additional note (as if I didn't ramble enough already)

I have tried other similar programs to MM that have a similar layout/interface and the cache thingy works the way I would like and the way MM used to

I am not suggesting that MM is inferior or anything of the sort, rather that this is possible, and maybe it can be looked at

nohitter (and others) - you have been more than helpful on this an many other subjects throughout the years

I do not want my comments to be viewed as complaining, rather features of MM I'd like to see changed/improved. I certainly do not think that letting go of the scroll bar is a big deal. I just would prefer it work differently.

I guess a little frustration exists, in that it did not always function this way. Though, I do realize that this behavior is likely the result of application-wide improvements, and this is the "collateral damage". Also, I use MM the most on my living room HTPC on a large screen, often in social situations. This behavior is amplified in this setting, and has even been pointed out by several people that have no experience with MM.

I am not intelligent enough to understand how/why the functionality of the cacheing changed, I would just like to see it work the way it used to. I doubt that it is impossible to accomplish, but may be extremely difficult. I would like to know if it can or will be fixed.

Thanks
BP

wdpaynter wrote:Am I, or are we, alone in preferring this not be the expected behavior?

Of course it isn't preferred. But its worth knowing that this isn't necessarily a bug with only some people's systems, and that it's like this for everyone. And its really not that bad to just let go of the scroll bar... just saying...

Am I, or are we, alone in preferring this not be the expected behavior?

I am 100% certain that it was not always this way. I seem to remember discussing this in a thread a year or two back. And I believe then there was a major update to MM, and the cache method changed, resulting in the current behavior. I will search for this when I get time.

Can anything be done to "fix" the cacheing method?
Thanks
BP

wdpaynter wrote:I too, am still experiencing this issue. I use Album Art+ Details, and when I have more than a few albums for an Artist, when I scroll down it takes a few seconds for each Album Cover to display and the last one will not display until I let go of the mouse button. If I have a lot of albums and scroll down quickly, albums in the middle are not "populated". It always requires bringing an album in to view and stopping shortly to allow the art to display.

That's the same for me, I think it is the expected behavior.

I too, am still experiencing this issue. I use Album Art+ Details, and when I have more than a few albums for an Artist, when I scroll down it takes a few seconds for each Album Cover to display and the last one will not display until I let go of the mouse button. If I have a lot of albums and scroll down quickly, albums in the middle are not "populated". It always requires bringing an album in to view and stopping shortly to allow the art to display.

It used to be (quite a few releases ago) that when you clicked on an artist (or any node) in the tree, all of the album art "populated" in the AA+Details window, so when you scrolled down, all the art was already there.

I really wish that this ability would return because it looks really sloppy the way it currently works.

Anyway this can be fixed??
Thanks
Bill P

Do I need another build? I don't understand why I'm still having this problem...

Anybody know?

nohitter151 wrote:

Sway wrote:So am I correct in concluding that this 'bug' should be fixed now? Cuz I'm still experiencing this (very annoying) issue.

Is there a configuration I'm overlooking or something? I'm using build 3.2.0.1294...

Thanks!

Yes, should be fixed as of the current build.

\

Ok, so then why am I still experiencing the problem?

Sway wrote:So am I correct in concluding that this 'bug' should be fixed now? Cuz I'm still experiencing this (very annoying) issue.

Is there a configuration I'm overlooking or something? I'm using build 3.2.0.1294...

Thanks!

Yes, should be fixed as of the current build.

So am I correct in concluding that this 'bug' should be fixed now? Cuz I'm still experiencing this (very annoying) issue.

Is there a configuration I'm overlooking or something? I'm using build 3.2.0.1294...

Thanks!