Is there anything unusual about the valentina and xenovia shifts? My Avg Hs on Workers/Shifts looks about 25% short (as does winry by a smaller amount too):
4keyk yuno 2015-05-10 22:38:48+00 48m 0s 3.784M 5.64THs 2.928k 1,292.34
4kesx xenovia 2015-05-10 21:52:18+00 46m 30s 3.117M 4.80THs 2.395k 1,301.33
4kenh winry 2015-05-10 21:03:17+00 49m 0s 3.706M 5.41THs 2.853k 1,299.13
4kefr valentina 2015-05-10 20:15:54+00 47m 23s 3.052M 4.61THs 2.351k 1,298.34
4kea9 ur 2015-05-10 19:28:47+00 47m 7s 3.814M 5.79THs 2.923k 1,304.91
4ke4p tenshi 2015-05-10 18:41:47+00 47m 0s 3.827M 5.83THs 2.929k 1,306.62
4kdx6 sena 2015-05-10 17:53:17+00 48m 30s 3.951M 5.83THs 3.028k 1,304.92
4kdrg rika 2015-05-10 17:05:48+00 47m 30s 3.900M 5.88THs 2.992k 1,303.43
4kdkw quinn 2015-05-10 16:17:46+00 48m 1s 3.850M 5.74THs 2.948k 1,305.83
My miners don't show any failover and report hashing away at 5.8T-ish during that time, so I found the stats peculiar when I saw them.
I always thought it was normal for the shifts to show less than the machines show? It's not!?
No this is just those 3 shifts - that it would seem my ckdb restarts this morning affected.
I did notice an unexpected shift summarisation during each of the restarts (it's not planned to do that and hasn't before) but I'll have to make the code more 'forceful' about that and also do more checking to be sure that's the exact cause.
I'm looking into the cause and then will have to fix it (for everyone)
Glad you found it so soon after, since to regenerate a small amount of data (less than a day) is way better than having to do it much after the fact.
Of course it will only be those 3 shifts in the middle, but from ckdb's point of view it's easiest to just push the shift processing back to before the problem and have it regenerate everything from then forward.
There is a full log of all shares and I've found for those 3 shifts the totals don't add up for you and of course will be the same for everyone.
This may take me a bit to sort out ... working on it