Chk box not working for me

[PeterSt]

Russ,

I actually do not want you to approach it like that;
The 9GB for disk space is obviously no problem. The "load time" as such, is unrelated either !! It just doen't work like you logically will think. You can say it's smarter than normal logic.

But there are other things which incur for a perceived slower "load time", and they are cpu bound and again unrelated to the amount. Trust me.
There are a few things that are - so far - beyond my understandings, never mind I created it myself; I have one source folder consisting of some 1000 albums only, which is hardly manageable when it comes to the response is requires. When this source is incorporated in a general Gallery, that becomes as slow, although it seems to average out with the rest of the contents of that Gallery.

So, there is just something wrong in "some" situation, and I have to find out what it is. I know this for some weeks now, but didn't spend the time on it yet.

It *is* true that a larger picture takes more time, BUT this only works out as a pain when it shows up in the CoverArt Area (rightmost pane);
It *is* true that at Selecting the lot in the middle pane (as you described earlier today) just the same phenomenon causes the lot to be superslow. But this is wrong by itself, and the selection should not show up in the right pane. That's a bug.

So only - and only then - when you click an item in the middle pane, it is "legit" that this is slower because of showing large pictures in the right pane. Do NOT shrink *those* pictures to 500x500 whatever, because logic tells that large pictures are there for readability (like the back of a cover, the inlay, etc.). Shrink those to 500x500 and you won't be able to read it anymore.
And yes, those readable pictures can 6MB or even more. But again, they only bother when you click an item in the middle pane, and when you're in a process that this slows down all the time, untick the Show Coverart box.
So, that this consumes 9GB does NOTHING. Just nothing.

Peter

[Calibrator]

Russ,

I actually do not want you to approach it like that;
The 9GB for disk space is obviously no problem. The "load time" as such, is unrelated either !! It just doen't work like you logically will think. You can say it's smarter than normal logic.

But there are other things which incur for a perceived slower "load time", and they are cpu bound and again unrelated to the amount. Trust me.
There are a few things that are - so far - beyond my understandings, never mind I created it myself; I have one source folder consisting of some 1000 albums only, which is hardly manageable when it comes to the response is requires. When this source is incorporated in a general Gallery, that becomes as slow, although it seems to average out with the rest of the contents of that Gallery.

So, there is just something wrong in "some" situation, and I have to find out what it is. I know this for some weeks now, but didn't spend the time on it yet.

It *is* true that a larger picture takes more time, BUT this only works out as a pain when it shows up in the CoverArt Area (rightmost pane);
It *is* true that at Selecting the lot in the middle pane (as you described earlier today) just the same phenomenon causes the lot to be superslow. But this is wrong by itself, and the selection should not show up in the right pane. That's a bug.

So only - and only then - when you click an item in the middle pane, it is "legit" that this is slower because of showing large pictures in the right pane. Do NOT shrink *those* pictures to 500x500 whatever, because logic tells that large pictures are there for readability (like the back of a cover, the inlay, etc.). Shrink those to 500x500 and you won't be able to read it anymore.
And yes, those readable pictures can 6MB or even more. But again, they only bother when you click an item in the middle pane, and when you're in a process that this slows down all the time, untick the Show Coverart box.
So, that this consumes 9GB does NOTHING. Just nothing.

Peter

ah ha .. thanks again for a broader explanation. I have likely assumed incorrectly that ALL the folder art needed to be loaded into memory at the same time, but thinking further about it, that wouldn't be the best way to do. The actual coverart data only needs loading into memory when that art needs 'displaying' in whatever manner. An index of some sort within your program would be a much faster method of keeping track of things I would think.

and yeah .. I wasn't going to reduce the additional coverart info the the point where it was unreadable. Kinda defeats the purpose then.

Cheers,

Russ