01/09/2014 22:43 CET ::
You are correct, there seems to be something off about the calculations. A while back I started to write some improved algorithm to generate the table, I'll check if there would be a fix so I'll continue on it, otherwise I'll search what else could be wrong.
04/09/2014 07:08 CET ::
I will wait for fix, because i love last.fm
19/09/2014 04:00 CET ::
Error still exist, i think error in date order direction.
When i'm choose 1 month, it shows not LAST month stat, but the first month, when i was registered to last.fm.
You need fix direction to date from ASC to DESC, something like that.
Now overall shows most correct result, becouse in this case direction not important.
20/09/2014 10:23 CET ::
I didn't had time yet to properly investigate. I hope to have some time next week to look at the problem as it needs to be fixed asap.
But thanks for the feedback, that information will surely help!
The calculations for the ranges are the same as for the overall, so it's a bit strange. Also the calculations arn't easy either as all the values are diffed at the time you want to watch the results in the table.
But I think there is a bad update of the artist playcount on the ranges as they can also decrease in playcount.
I'll give some feedback when I find something strange ;-)
20/09/2014 11:11 CET ::
I've found out the artists which got removed from the ranged list fetched from last.fm didn't got removed from the database. Also if a playcount didn't changed the date didn't got updated into the last update, so that artist wasn't taken in the calculations for the genres/tags. So it seems there is something wrong in calculating the right records to update/remove the records in the database. I'm testing the changes, once when they seem to be more correct I'll check if the overall is still ok, because I have a feeling that there are some detail calculations which may be a bit off now.
20/09/2014 23:26 CET ::
I made some changes to the saving of the artist count for a user on the ranges. Normally it shall be correct now, we'll just need to wait for the results to show up when the update happens. (Note that we'll need at leas an update to correct the current count, after that every update should show correct percentages) The previous data which is a bit off can't be changed anymore.
14/12/2014 10:04 CET ::
Now it's better, but when select 1 o 3 month you still have bug with tracks per date count.
14/12/2014 10:05 CET ::
Now it shows for me +900 per day, but 13 in stat only.
21/12/2014 00:56 CET ::
Ah you mean in the image, it seems a bit odd indeed. When I get some free time, I'll check what could be going wrong. I'll keep you posted
24/12/2014 15:44 CET ::
I found out that the table wasn't correct, negative values whern't shown. I corrected it for the next update. Tho I have a few things I want to fix/change and a few new features I want to add. So the update will be over a few days.