got me just as i stepped away from my desk, lol. i’ll have a look in a sec
2025-12-22 35619, 2025
mayhem[m]
no rush. bed time here.
2025-12-22 35625, 2025
julian45[m]
<mayhem[m]> "julian45: http://mapper...." <- formatting looks good - now i just need to make sure it'll actually be handled properly by a collector
2025-12-22 35613, 2025
julian45[m]
so i'll do some quick mocking in docker on my end; meanwhile, zzzzzz time for you
2025-12-22 35640, 2025
mayhem[m]
# TYPE lbmapper_rss gauge
2025-12-22 35644, 2025
julian45[m]
s/quick/testing/, s/mocking//
2025-12-22 35657, 2025
mayhem[m]
* # TYPE lbmapper\_cache_items gauge
2025-12-22 35615, 2025
julian45[m]
* so i'll do some testing in docker (emulate collector and visualizer) on my end; meanwhile, zzzzzz time for you
2025-12-22 35618, 2025
mayhem[m]
what should the gauge be for a value that is randomly fluctuating over time, julian45 ?
2025-12-22 35635, 2025
julian45[m]
i mean, as a measured value at point-in-time, a gauge should be appropriate based on the [possible metric types](https://prometheus.io/docs/concepts/metric_types/#gauge)
2025-12-22 35645, 2025
julian45[m]
* be appropriate type based on
2025-12-22 35632, 2025
julian45[m]
if we want to just make sure it's not getting large at some point in time, i would Think we can handle that math grafana-side?
2025-12-22 35646, 2025
Jade[m] joined the channel
2025-12-22 35646, 2025
Jade[m]
Yeah generally it's up to the query to distinguish between a rate and a value, because a rate is just a derivation of a value
2025-12-22 35631, 2025
julian45[m]
i.e. rates can be derived from exposed values, especially when having the app track rate internally would be computationally expensive
2025-12-22 35640, 2025
Jade[m]
integer overflows are handled by restarting your server 🧌
2025-12-22 35650, 2025
mayhem[m]
those docs are not helping my tired mind.
2025-12-22 35659, 2025
mayhem[m]
> the count of events that have been observed, exposed as <basename>_count
2025-12-22 35629, 2025
julian45[m]
don't worry about histogramming anything
2025-12-22 35630, 2025
mayhem[m]
mayhem[m]: this is what I want, but its not clear exactly how that translates to the output
2025-12-22 35639, 2025
julian45[m]
at least at this point imo
2025-12-22 35651, 2025
mayhem[m]
I'll continue tomorrow to show number of cache items.
2025-12-22 35619, 2025
julian45[m]
yeah - it would be fine to just show # of cache items at observation time as a gauge
2025-12-22 35602, 2025
outsidecontext[m has quit
2025-12-22 35617, 2025
julian45[m]
histograms/summaries are more appropriate for e.g. sorting observations of request response times into buckets. onus for calculating those is usually a client library in a given programming language, and i'm guessing that integrating one into the mapper would be more brain-cycle-expensive, and calculating such metrics would be more computationally-expensive, than would be worthwhile
2025-12-22 35602, 2025
Kladky has quit
2025-12-22 35609, 2025
v6lur has quit
2025-12-22 35634, 2025
julian45[m] uploaded an image: (133KiB) < https://matrix.chatbrainz.org/_matrix/media/v3/download/julian45.net/4RiE5YNoSE8CqHb88Es5H4twEk01nHKB/Screenshot%202025-12-21%20at%208.56.33%E2%80%AFPM.png >
2025-12-22 35656, 2025
julian45[m]
some fiddling later, this stuff is clearly parseable by telegraf, woot
2025-12-22 35657, 2025
julian45[m]
so we're set on basic validation 👍️
2025-12-22 35629, 2025
julian45[m]
* telegraf, woot (just wanted to make sure as a matter of practice + wasn't sure how necessary some bits of some headers were)
2025-12-22 35622, 2025
anuj_[m] joined the channel
2025-12-22 35622, 2025
anuj_[m]
jasje: Hemang Mishra:
2025-12-22 35623, 2025
anuj_[m]
I found a bug in the ListenBrainz app. When tapping the search icon from the Feed, Explorer, Profile screens, it works correctly. However when on the Player screen tapping the search icon does nothing. I am not sure whether this behavior is intentional or a bug please clarify.
> I found a bug in the ListenBrainz app. When tapping the search icon from the Feed, Explorer, Profile screens, it works correctly. However when on the Player screen tapping the search icon does nothing. I am not sure whether this behavior is intentional or a bug please clarify.
2025-12-22 35642, 2025
HemangMishra[m]
Good catch, this seems to be a bug. You’re welcome to work on it 👍
2025-12-22 35634, 2025
anuj_[m]
HemangMishra[m]: Sure,I will create an issue
2025-12-22 35657, 2025
Miblo has quit
2025-12-22 35653, 2025
dabeglavins682 joined the channel
2025-12-22 35624, 2025
dabeglavins6826 joined the channel
2025-12-22 35655, 2025
dabeglavins682 has quit
2025-12-22 35655, 2025
dabeglavins6826 is now known as dabeglavins682
2025-12-22 35638, 2025
FaizanAkhtar[m]
* I am not a mentor....!! maybe yes.... wait for the mentor to reply
lucifer, ansh : I am going to be on vacation from tomorrow onwards, so I'm quite keen to get the rest of YIM merge and ready.... (full message at <https://matrix.chatbrainz.org/_matrix/media/v3/download/chatbrainz.org/KNiOnRYzAzYUxmSGcTbjVgfZ>)
2025-12-22 35605, 2025
lucifer[m] joined the channel
2025-12-22 35605, 2025
lucifer[m]
monkey: sounds good to me. the email was the only remaining thing that I could think of.
2025-12-22 35639, 2025
monkey[m]1
There are some PRs piling up that need your review, so we can calculate the data for the missing graphs, apart from that I think nothing big
2025-12-22 35647, 2025
lucifer[m]
As for the earliest YIM year, how far back do you want to go?
2025-12-22 35653, 2025
lucifer[m]
i'll check the PRs.
2025-12-22 35638, 2025
q3lont has quit
2025-12-22 35624, 2025
lucifer[m]
oh I had already reviewed those PRs and even tested on prod. but either forgot to mark on Github or it didn't register.
No I think that's the two open ones. Ansh was also working on something to get the top cover art for each year in a single query on load
2025-12-22 35607, 2025
monkey[m]1
<lucifer[m]> "As for the earliest YIM year..." <- I had in mind 2002 which is the earliest data we accept listens for I think.
2025-12-22 35607, 2025
monkey[m]1
I'll need to review the year selection to account for that, currently it's only set for 2021-2025.
2025-12-22 35631, 2025
lucifer[m]
yes, 2002 makes sense to me.
2025-12-22 35638, 2025
monkey[m]1
Not sure how to treat years the user doesn't have data for.
2025-12-22 35623, 2025
monkey[m]1
But I suppose the same query that will fetch the top cover art for that year will inform how many years to display
2025-12-22 35642, 2025
monkey[m]1
lucifer: are you free for a video call at 7PM IST?
2025-12-22 35643, 2025
monkey[m]1
Ansh and I are going to start a call 30 minutes before that to discuss the front-end, then all 3 of us can have a quick chat to make sure we're all on the same page?
