(2017-03-14, 00:18)marcelveldt Wrote: (2017-03-13, 00:46)brazen1 Wrote: I thought this was a very good suggestion. I didn't even know the setting existed. I just tried unchecking every view except horizontal, the only one I use. I went to browse the library. It won't budge until the drive(s) spin -up. I can hear the drive spinning up while it's stalled. Once the drive has spun-up, I can navigate..... until I come upon a title that resides on another drive that has not spun up yet. Once it too spins up, I can resume navigating until I come upon yet another drive containing that metadata and have to wait again. Attempting to navigate by holding down the scroll results in a crash every time. Again, I don't know if it's just my system or if this is prevalent for everyone.
I'm not 100% sure how it works exactly but my best guess is that it's trying to grab something from the disk.
Most definitely it will be the artwork but it shouldn't do that because that is cached locally.
Something is off either in the skin code or in your specific setup and I'd like to work with you to sort it out.
Are you available for some debugging ? In that case I will send you some special test versions of the skin and some actions to perform in order to sort out where the issue is.
While the artwork is "cached" as thumbnails, there are two 'reference' pathways to those thumbnails.
Case one is when the metadata reference is actually available in the Kodi databases. In this case, the skin can look up the metadata directly from the database and obtain the 'cached' path to the thumbnail. In this case no reference to the actual backing file system is required.
Case two is when the metadata reference is not available in the Kodi video/music database (e.g. extrafanart, posters, banners). In this case, while Kodi still *reads* the files from the thumbnail 'cache', it can't get the reference from the video/music database directly. It seems to do a query on the filesystem to get 'path information' and then using the filename it then looks up the thumbnail location in the texture database. So the reference info is still obtained from the filesystem. (You can see this if you watch Kodi with a tool like the sysinternals 'procmon' -- this only works for windows, of course). It's the query on the file that causes the 'blocking' system call while your disks spin up.
I'm not sure you can avoid all occurrence of case two 'lookups' unless you were to actually make extensions to the Kodi video/music database.
My solution for Kodi and every other media centre I've used (MCE, Plex, Emby, etc.) is to run disks 'always on'. Since my media is stored in a RAID/ZFS/Storage Spaces type system, the 'always on' option with disks that are designed to be 'always on' (e.g. WD RED) is a natural one for me. The thumbnail solution still helps with performance as the media can be loaded from an SSD instead of slower drives (local or network).
my 2 cents.
