Posts: 4,545
Joined: Jun 2015
Reputation:
269
It would be unsurprising for a Windows version to produce different folder path hash values from a non-Windows version (CoreElec is on RPi?). This cross-platform path hash sensitivity is something that might eventually be resolved with the futher changes to system time functionality that are coming.
But are you experiencing repeated deep updates from same nightly and same flavour of platform?
If you have multiple Kodi clients on various platforms connecting to a database on a server then I recommend that you only run library update from the client with the fastest server access and most powerful processor.
Posts: 1,234
Joined: Mar 2011
Reputation:
80
2020-03-03, 22:31
(This post was last modified: 2020-03-03, 22:33 by HeresJohnny.)
I had some time to investigate this further and installed two Kodi v19 portable nightlies of 2020-03-02 on two different Windows 10 machines with the same Windows version and revision. While I was at work, I let one of the machines update the library which lets it go through the deep scan that occurs after that patch. All albums were shown as newly added after that. Then I started the library update again to confirm that everything was scanned in correctly and indeed, that second run was as fast as expected.
Next I opened Kodi on the other machine and triggered a library update. The update went through a deep scan again but no albums were shown as newly added. On running the library update on the first machine again, yet another deep scan ocurred.
This means, that hashes calculated vary from machine to machine. I don't know how small a time-fraction is involved in generating hashes but if it's microseconds or atomic values the smallest time difference might trigger a deep scan. If the display of newly added albums uses a more coarse time-scale like minutes, that could explain why no new albums were shown between the various runs.
My recommendation at this point would be to use a more coarse time to generate hashes (if time is indeed a factor), at least for some tests. I'd be willing to run test builds on my windows machines.
Posts: 4,545
Joined: Jun 2015
Reputation:
269
Sorry but no that will not be reverted. Why not simply use one client to initiate the library update rather than whichever one you happen to be using at the time. It is a very simple user workaround.
It is behaving as if the calculated hash values vary from machine to machine, but I have not been able to reproduce this myself.
Also I don't think hash calculation is dependant on the system time of the machine doing the scanning, but on the file name, size and timestamp returned for the music files. I assume that the music files are on a server or NAS drive, do both your machines see the files as having the same name, size and timestamp? I can't think why they wouldn't but it is worth checking.
Posts: 1,234
Joined: Mar 2011
Reputation:
80
2020-03-14, 15:34
(This post was last modified: 2020-03-14, 15:40 by HeresJohnny.)
I may not have been clear enough, but the rescan also happens on the same machine after some time. The "server" is simply a networked Windows computer with attached storage. The external drive is a WD MyBook 8TB with the file system formatted as exFAT.
Posts: 1,234
Joined: Mar 2011
Reputation:
80
2020-03-14, 19:53
(This post was last modified: 2020-03-14, 19:59 by HeresJohnny.)
Well, chances are that it's something on my side since noone else has come forward... I'll keep on digging. The first thing I'm going to do is re-format the drive as NTFS.
Posts: 4,545
Joined: Jun 2015
Reputation:
269
I was wondering if that PR would help it sounded related, but tracing through could not see it being used during hash creation. So yes, do try it and report back.
