Open mjordan opened 6 years ago
OK, I think I might be going crazy. Now this chart is rendering properly:
I hit it again to reproduce a warning from Firefox I was getting earlier saying that something on the page https://arcabc.ca/islandora/object/kora:43 was slowing my browser down, did I want to stop or wait? Now I don't see the warning and the chart is rendering correctly. Just checking it in Chrome now and it works correctly too. Maybe my hitting a few times tonight has changed the stats such that it fixed the problem? I am not kidding when I say that there is a Heisenberg effect sort of thing that happens when you are debugging these charts (see my comment at the end of https://github.com/mjordan/islandora_usage_stats_charts/issues/14#issuecomment-377535243 about "now" changing every second.
It's bizarre. Something weird going on with those counts. There is no way that there were 22,000 downloads of that object in a given month.
@bondjimbond is this issue still a thing or has it been resolved by some of the other recent fixes, e.g. #18 and #20?
Hard to say, since the black chart thing is unpredictable. I had seen it a few times since re-enabling Charts after the download count bug was fixed. I haven't seen it since the increments were fixed -- but then, that was very recently, so can't tell whether or not it's gone.
Originally asked in https://github.com/mjordan/islandora_usage_stats_charts/issues/14.
What is going on with this chart?
I suspect the wide difference between the smallest bar (2017-10) and the largest (201-01) is compressing the chart so that it is rendering strangely. However, hunting around for chart.js bugs doesn't confirm that suspicion.
To eliminate the 2018-01 bar temporarily to test this, can you temporarily change the months shown to 3 and see if that chart renders normally? If it does, we may need to think of a way to dynamically check for very wide differences in the raw data before it gets sent to chart.js, or come up with some other way of preventing this from happening,