Thumbnail cache not working ?

[Telstar]

PS: the thumbnails of the gallery do not cache completely. Scrolling the library is very cpu or gpu dependent.
this is what i meant in the gallery interface to be not responsive (cant find that thread so i'm writing it here).

[AUDIODIDAKT]

PS: the thumbnails of the gallery do not cache completely. Scrolling the library is very cpu or gpu dependent.
this is what i meant in the gallery interface to be not responsive (cant find that thread so i'm writing it here).

Huh,

Telstar,
Cache-size on max (1920) and do you have gallery on SSD ?
Thumbs must be cached first (to the max of 1920), so scroll thru your genre once slowly till all is cached.
Next time you go thru that section, it will be lightning fast.

Do you mean this, your problem layout is sometimes a little on the short side, if I may say so
I thought "we" (us users) were happy about gallery speed now, or do you still encounter lack of responsiveness ?

I have Quad core @ 3.40 and a 9800GTX (not optimal for audio), you have E5800 ? dual core and on-board (optimal for audio), this shouldnt matter that much, does it ?

(D)Roy(d)

[Telstar]

Cache-size on max (1920) and do you have gallery on SSD ?
Thumbs must be cached first, so scroll thru your genre once slowly till all is cached.
Next time you go thru that section, it will be lightning fast.

If I'm correct, the cache is gone after i reboot the pc, which makes it pointless.

Do you mean this, your problem layout is sometimes a little on the short side, if I may say so
I thought "we" (us users) were happy about gallery speed now, or do you still encounter lack of responsiveness ?

I have never been happy with it. It is decent on my studio pc (3ghz core2d and gtx280). But not perfect there either. It SHOWS that is not cached.
And I surely should not do this procedure everytime i boot my pc.

[AUDIODIDAKT]

Maybe you turned off CPU caching in BIOS or something related, it happens on both your "fast" PC's
Must be related to your settings you made on both of your rigs.
This problem "lays Around" your cpu.

Did you resized all your coverart properly (folder.jpg) and other "showdata" stuff.
xx has bulk resize options now !
Check your thumbnail (library) settings

[Telstar]

Maybe you turned off CPU caching in BIOS or something related, it happens on both your "fast" PC's
Must be related to your settings you made on both of your rigs.

No.

Did you resized all your coverart properly (folder.jpg) and other "showdata" stuff.
xx has bulk resize options now !

Yes, but i kept some huge files (max 2000x2000 pixels). Probably is this. Since the data is the same in both computers.
I resize jpegs only with Photoshop - any other program causes artifact and double compression.

[PeterSt]

I resize jpegs only with Photoshop - any other program causes artifact and double compression.

Uhm, not XXHighEnd itself !
Btw, see Resize Coverart 0.9y-5 (more advanced useage).

But it is true ... Before I resized my pictures to normal sizes (see the link for "normal sizes") there was no way I could get rid of the sluggyness. On this matter, notice this isn't about the simension (as in 2000x2000) *at all* but about the byte size. Just go have a look, and you will see that many of them are over 10MB (or even many factors more), which is completely stupid (but a standard by some unknowledged uploaders ). Again, see the link for my own perception of this (and otherwise the ToolTips concerned).

Also, cacheing doesn't help for this because the sluggyness is not about reading the picture from disk, but about formatting it in memory. So, even when it's in the cache, that formatting always has to happen. Now take your calculator, and see that e.g. 500x500 is 16 times as small as 2000x2000, and thus takes 16 times as long to process. But be careful, READ THE LINK, and notice that you will WANT the 2000x2000 to be there for Coverart other than the front cover;
In the very end it is about the number of bytes used to store the picture, and a picture of 2000x2000 can be stored with an as good quality in 1MB as it can in 60MB. And yes, 60MB will me 60 times slower than 1MB.
Get the grasp of this, and you will be good (after resizing everything, for which only XXHighEnd is suitbale for what you want here, so TRY IT).

Lastly, please get the good idea about the cache;
This is not meant to be there forever hence all would disturb again after a reboot, it is there to help as a normal cache (which I won't explain here, but I guess Google will help you). Nothing more and nothing less, but sufficiently enough !! It is the "bad useage" which invalidates it all, including your thinking about the reboot (which is just allowed/necessary/shouldn't bother etc.).

Ok, at least know I understand where this comes from, and this includes the "more slow" since a version. On this, I would wish you people read the release notes better, because all is just in there, including the reinstallment of a before eliminated slow-down feature "which now won't bother anymore" (and which is true at normal usage, which is not the case with scans of 60MB).
So Telstar FYI and to be clear : You are correct that since "that" version things got slower for you, and this is (almost totally) unrelated to higher demands from the system because of KS useage. I just reinstalled a slowing down feature, necessary to get the right pictures (so the back won't show where the front is wanted, etc.).

Lastly, you can just listen as well to Roy, because it was he with whom this all was worked out with as the subject some 8,000 albums with ridiculously sized pictures (and I'm talking over 100,000 pictures here !). Btw, there are still some improvements pending on this.

Good luck now !
Peter

[Telstar]

Btw, see Resize Coverart 0.9y-5 (more advanced useage).

But it is true ... Before I resized my pictures to normal sizes (see the link for "normal sizes") there was no way I could get rid of the sluggyness. On this matter, notice this isn't about the simension (as in 2000x2000) *at all* but about the byte size. Just go have a look, and you will see that many of them are over 10MB (or even many factors more), which is completely stupid (but a standard by some unknowledged uploaders ).

That's what I did. I remember I resized all files too big of the main folder (the FLACs). Now i dont know from which byte size i started. Probably not enough.

Will check the thread, thanks!

[AUDIODIDAKT]

Telstar read it carefully ! (especially when doing the whole bunch at once)
Its all in Peters guide

Back-up the original covers (see guide), just to be sure (also to compare)

also:

Make Folder.jpg (Main Coverart) about <=1MB, 640x640 (or maybe the same setting as your unattended cover size)
Make other coverart (Showdata Stuff) <=1MB, 3000x3000 or maybe in your case leave 2000x2000

if covers are about 2-3 MB or bigger you have to resize, especially when you have like 10 of such big covers per album.

Thank Peter for it, he did great on this !

[Telstar]

Make Folder.jpg (Main Coverart) about <=1MB, 640x640 (or maybe the same setting as your unattended cover size)
Make other coverart (Showdata Stuff) <=1MB, 3000x3000 or maybe in your case leave 2000x2000

if covers are about 2-3 MB or bigger you have to resize, especially when you have like 10 of such big covers per album.

FIY, I dont use the other stuff. In each main album folder there is just folder.jpg and back.jpg (75% of the times).
IF the albums have a scanned booklet, that's in a subfolder which i THINK (Peter?) is not cached. I do not use the alternative covers feature.

Will check the sizes tonight since i have some free time (yay!)

[AUDIODIDAKT]

If pics are shown they are cached, even in sub folders.
You could try to disable the "showdata" setting. (or you already have)

Correct me if i'am wrong Peter !

[Telstar]

If pics are shown they are cached, even in sub folders.
You could try to disable the "showdata" setting. (or you already have)

Correct me if i'am wrong Peter !

Thanks. I already have.
Maybe the subfolders with pics are still cahced?

[PeterSt]

Hi Telstar - In the end it is either :

- Too large pictures
- Too much demand from the PC (too low latency to do enything else, which will be the case with any setting of KS Special and Adaptive Mode
- A slomo PC, in your case - per your descriptions - caused by the CPU.

Especially keep in mind the second option, because I sense that you don't feel this, while you're always playing Attended.

Peter