2017-03-04, 13:21
I run a library update on boot and often Kodi sits on "preparing....0%" for often 15-30 seconds before doing anything. Then the library update proceeds as normal (typically takes another 5-10s)
I believe this is because Kodi is trying to access posters on disks which are spun-down and excluded from the library update process. It's causing the library update to hang while it waits for spinup or timeout.
(My library is stored on multiple independent disks on a network server. Most of these disks do not get any new content so I exclude the relevant folders from the library scanner to speed up the update. And selectively allow those disks in my server to spin down. Disks with incoming content which are included in the Kodi library update scope are never spun-down)
During the library scan I can see in the log that Kodi is trying to access content on those disks, which it should not be doing.
For example, the folder "Movies 1" receives no new content, is therefore excluded from the library scan, and resides on a disk which is spun-down. Here is my update log:
We can see it sits for 11s because it is waiting to access a poster on Movies 1 which is excluded from the scan. This example is best case, it can be worse if it tries to access posters on multiple spun-down disks because it seems to do this operation in series.
The other downside is that it is spinning up disks which I don't want to be spun up.
So my question is: why is Kodi trying to access posters on disks which I have excluded from the library update process? These posters should already be cached into Kodi's db. Is this design behaviour? Is there anything I can do to prevent it? Will a shorter Samba clienttimeout value shorten this delay?
Thanks
I believe this is because Kodi is trying to access posters on disks which are spun-down and excluded from the library update process. It's causing the library update to hang while it waits for spinup or timeout.
(My library is stored on multiple independent disks on a network server. Most of these disks do not get any new content so I exclude the relevant folders from the library scanner to speed up the update. And selectively allow those disks in my server to spin down. Disks with incoming content which are included in the Kodi library update scope are never spun-down)
During the library scan I can see in the log that Kodi is trying to access content on those disks, which it should not be doing.
For example, the folder "Movies 1" receives no new content, is therefore excluded from the library scan, and resides on a disk which is spun-down. Here is my update log:
Code:
10:51:09.850 T:140012221847296 DEBUG: GetImageHash - unable to stat url smb://MY-DESKTOP/Movies 1/Big Buck Bunny/Big.Buck.Bunny.720p.BluRay.x264.DTS-poster.jpg
10:51:21.241 T:140013528798976 DEBUG: VideoInfoScanner: Skipping dir 'smb://MY-DESKTOP/TV Shows 2/24 Legacy/' due to no changeThe other downside is that it is spinning up disks which I don't want to be spun up.
So my question is: why is Kodi trying to access posters on disks which I have excluded from the library update process? These posters should already be cached into Kodi's db. Is this design behaviour? Is there anything I can do to prevent it? Will a shorter Samba clienttimeout value shorten this delay?
Thanks
