[Bluck Mutter]

So I have 5000 "music videos" (technically these are FLAC music albums ripped from CD's then regenerated as .mov videos so I can use lossless ALAC).

Assume a structure of genre/alpha/artist/album.mov  (where alpha is A,B,C,D etc)

Technically there is no metadata associated with the MOV files.. so no scanning/scrapping involved

Each artist subdir has the album MOV's plus a thumb.jpg image that is the album cover art. I also use banner.png, fanart.png and poster.jpg that I programmatically generate to store images of such info as the track list, musicians on the album etc. that I can display in my custom skin.

What I notice is when browsing, even though the .kodi/userdata/Thumbnails is fully populated, that displaying the album art under a specific artist takes say  two or three seconds to display the first row of albums. This is irrespective of how many albums an artist has... one with 3 albums is slow... you can see each cover art image being display serially, one after the other.

Then if I go elsewhere and then come back to say the first artist I browsed, the cover art display is much snappier (assuming its now in the Kodi cache some where)

This slowness makes no sense to me. All the images are cached in  .kodi/userdata/Thumbnails so it shouldnt take Kodi that long to read some small jpg's (say 8k-12k in size each) off an ssd drive on a system with 16GB of memory and a recent I7 cpu. I have tested this on various systems as my videos are stored on a USB 3.1 external drive encloser (noting not a NAS). I can push 400MB per second writing to this drive so its not a dog.

I am using the preloaditems tag but this issue is related to the first 8 albums displayed in the panel. When paging down, all subsequent artwork is displayed quickly.

Is there some tweak in the Kodi setup (I have looked) or is there some way to pre-load the  .kodi/userdata/Thumbnails  images into the Kodi cache to speed this up... its really annoying.

Thanks,

Bluck

[izprtxqkft]

I am using the preloaditems tag but this issue is related to the first 8 albums displayed in the panel. When paging down, all subsequent artwork is displayed quickly.

with preloaditems on wouldnt it load all albums not just the first 8 and therefor this is why there is an initial delay but then scrolling down there is no delay?

i wonder what the behavior is when preloaditems isnt used

[Bluck Mutter]

So I ran "nmon" and looked at the disk/cpu activity and what it showed lots of writes (of which all would be Kodi given nothing else was running) when going into an artist with say 40 albums (aka videos).

So I want back into settings and had another look around and found a setting under media->videos called artwork.

There was an option called "artwork level" which was set to "maximum"

I changed this to "basic" and made sure anything related to "extract" or "download" was set to off (especially extract thumbnails).

This did improve the display speed of artwork on the first page substantially and running "nmon" after this changed showed minimal disk writes.

So I can only assume that under "maximum" mode it was, for example, extracting thumbnails every time despite there being a user provided thumbnails.



I will keep testing and see if the issue has truely gone.

Regards,

Bluck

[izprtxqkft]

right on

[fritsch]

Can you create a Debug Log with component logging of curl and filecache enabled?

[Bluck Mutter]

sure

will turn back on "maximum" and generate the log.

Will do that tomorrow

Thanks,

Bluck

[Bluck Mutter]

I note in https://kodi.wiki/view/Artwork/Cache that part of the cache workflow states:

If the image is not from a web service (HTTP/S) and at least 24 hours have passed since it was last loaded, 
check the hash generated in step 3 of "The caching procedure" for changes to the image. 
If the hash has changed, cache the new image as outlined in the section above.

This potentially explains why I have seen signifcant (all relative of course) read activity when browsing areas of my videos that I know have been cached (i.e. I can see the images in the texture database and at the filesystem level).

Looking at the texture database we see:

CREATE TABLE texture (id integer primary key, url text, cachedurl text, imagehash text, lasthashcheck text);
CREATE TABLE sizes (idtexture integer, size integer, width integer, height integer, usecount integer, lastusetime text);

Havent looked at the cpp code yet to see which of these columns is the trigger column for the hash check but suspect its the later.

Therefore if I have a stable image set (which I do) then I can have a process that starts whenever my system boots that ensures the lasthashcheck and/or lastusetime  is populated with a timestamp related to the system start time.

This will, in theory (yet to test this) ensure that no additional system resources/time/reads is used by Kodi when displaying artwork etc. Easy enough to check if it works by changing my system time to force the > 24 hour check.

Every second counts in the mission critical world of video playback!!!

Bluck

PS. I am not a "weekend warrior" when it comes to application/system tuning having spent decades tuning complex applications and large databases (think 5k or more concurrent application/database users)