[BatterPudding]

Small little geeky question about the Music database.

In the paths table, there are three fields: idPath, strPath, strHash

Do I assume that strHash is not aware of the clock changes?  So when the clocks swap between summer and winter time the hashes all get invalidated?

Does this explain why all my idPaths run from 91352 to 96524 ?  Have they all been recalculated at the last clock change?

Just seems strange to me to have nothing in the low values...

[DaveBlake]

Yes, it does seems that at least on some platforms the hash creation is clock change sensitive. The symptoms are exactly as you desribe, after clock change when library update is run the hash check looking for files or folders that have changed mistakingly sees all paths as changed and rescans the contents. This will take time, so the user may notice it happen, and will cause some ids to be replaced hence have higher number range.

This is not by design, and I'll see if I can find where the hash creation (on some platforms) is not allowing for summer time.

[Have split your posts @BatterPudding because they really don't belong under how to move media files without losing rating values]

[BatterPudding]

Yes, it does seems that at least on some platforms the hash creation is clock change sensitive. The symptoms are exactly as you desribe, after clock change when library update is run the hash check looking for files or folders that have changed mistakingly sees all paths as changed and rescans the contents. This will take time, so the user may notice it happen, and will cause some ids to be replaced hence have higher number range.

This is not by design, and I'll see if I can find where the hash creation (on some platforms) is not allowing for summer time.

[Have split your posts @BatterPudding because they really don't belong under how to move media files without losing rating values]

Thanks.  I thought that is what I was seeing.  I call this bi-annual scan a QA feature and certainly not a bug.    A healthy refresh of the data which I wish I knew how to fire off manually.

And if you do insist on "fixing" this, then maybe just set all times to GMT.

I think it occurs for me because I am on Windows PCs here, using NTFS, but these files are accessed on a different PC via SMB.  That's usually enough of a chain to trigger upset of code written in the *nix world.

[tkgafs]

not sure if it helps in any way but,  I had this issue yesterday, when I noticed the time on raspberry pi was an hour out.

I discovered I hadn't set the timezone country and once corrected the next library scan did the full update

I am running on a pi but mounting smb shares from a debian server running samba