Ok, lemme try to test your PR and see if I find the issue
Freso joined the channel
Thank you so much!
akshaaatt: well, the first thing I'm seeing is "Refused to load the stylesheet 'https://firstname.lastname@example.org/dist/css/bootstrap.min.css' because it violates the following Content Security Policy directive: "style-src 'self' staticbrainz.org". Note that 'style-src-elem' was not explicitly set, so 'style-src' is used as a fallback." in the console.
We probably should have those stylesheets locally
But bitmap can tell you exactly whether to put them on staticbrainz or what :)
(if you want the whole result I can send it, it's 30 mb of text)
ok, thanks all good.
a lot of those are not what I would expect spammers to look like. though the "dry run" bits seem clearly spam accounts.
"but the absolute value of this metric is also not meaningful -- number of listens processed since ts writer start is meaningless." -> how so? that's what is called a counter in metrics world, and it's widely used. Your app just have to increase it over the time. For example, that's how we get rates from interfaces traffic (number of bytes since the start). But it doesn't work for temperature for example (for this, a gauge is used)
yes, I understand counters.
but this counter is counting something meaningless. the number of counts like the start of the component. I could care less. this is not about the validity of counters, it is about the validity of the metric we're measuring.
ah, yes, that's another issue ;)
well, most apps just counts number of hits, number of items, etc... since the start because that's convenient (you don't have to store anything to disk), and since, by definition, the value cannot decrease, when it happens points are just ignored.
ruaok: the graph for Incoming listens has no derivative anymore, is that expected? I also just noticed the use of fill(0) (that's perhaps me when I tried to fix those), it should be fill(previous) or fill(linear)
yes, just to reset the nonsense. I'll fix it when lucifer releases an updated timescale writer.
at least it is good to know the seekrit incantation on how to make this graph.
fill() is tricky, because it is only used when values are missing, and missing values depends on group by time(), for counters, we usually want to fill with previous values (when no values, we assume it didn't change), it can also be linear (but it then extrapolates too much imho)
ruaok: also trigger a full dump to fix missing pre-2018 listens?
absolutely. (no need to ask me this question in the future, you're the boss in this area)
intending to use the flags alastairp added last week to dump just spark listens first as that take ~4-5 hrs so can request import today and get stats fixed tomorrow. after that can trigger normal listens to complete the set of file (takes ~18-24 hrs).
I'm quite curious about the outcome of this -- the recheck on the mapping should have included a pile of new matches on the top discoveries. should be fun tomorrow.
oh. indeed then hoping tommorrow's stats to be better