BrainzGit: Hi, I made a little modification to the way the percentages were calculated to map the dates to the appropriate section of the page on the `/explore/fresh-releases/` page, please review it whenever possible.
lucifer[m]
@fettuccinae:matrix.org: what's your LB username?
<fettuccinae[m]> "image.png" <- this stats screenshot is correct because the range selected is last week, for current week's stats you need to select this week.
oh i see you mean, top artists/albums/tracks.
dvirtz[m]
reosarevok (@_discord_1151240977378463764:chatbrainz.org), I didn't build materialized tables, could this be related?
s1b1 joined the channel
SigHunter has quit
SigHunter joined the channel
BrainzGit
[listenbrainz-server] 14mayhem closed pull request #3140 (03master…master): Improved Nginx Configuration to Address Critical Issues in Production Environments https://github.com/metabrainz/listenbrainz-serv...
reosarevok[m]
dvirtz: not sure tbh, I can try and take a look in a bit, I can't imagine the materialized tables would be connected with link types tho
lucifer or monkey: are there known issues with last.fm imports? (see "Last.Fm import" at support)
OK, well, I think they were just impatient. Account created this morning, and now the LB profile has 370K listens imported from LFM, so I think it's working fine :)
Will write back
Yep, checks out with their lastfm history
2 listens missing out of 376.830 , that's a pretty good score
mayhem[m]
<relaxo[m]> "mayhem Hey, I want to improve..." <- hi! 1) yes. 2) yes 3). We're going to be creating release-release similarity soon. You could have the user select a few albums as seeds and then harvest artists from it and releases from similar releases. I find genres are not great for a primary discovery tool -- too messy.
reosarevok[m]
dvirtz: for type-info, it might be a cache issue
Since it checks the cache first
You could try to empty the cache (was that redis flushall? I forget exactly) or just change the code in the meantime in Controller/WS/js.pm to skip the cache check
reosarevok (@_discord_1151240977378463764:chatbrainz.org) I actually thought about it and ran `./admin/PruneCache` but it didn't help.
I'll look at `redis flushall`
reosarevok[m]
Worst case scenario just change unless (defined $response) { to unless (0) or something temporarily to re-load anyway, see if that does it
bitmap: I tested disabling `$use_hard_search_limit` entirely for a direct release search and I didn't notice it getting significantly worse, but I'm testing through a tunnel so not ideal conditions
That choice is 16 years old, anyway - possibly worth reconsidering
monkey: I have completed the backend for the thank you feature
I need some help in its frontend part
it seems really confusing :(
also, how should it look like?
should i make a PR with a commit for backend and partial frontend that i tried to implement?
it would be easier for you to review in that way ig
* make a draft PR with
monkey[m]
suvid: Yes, a PR (even if incomplete) is the best way for me to review. You can even create a draft PR if you prefer, or mark a PR as a draft.
Regarding the UI, the best plan of action is for you to make a visual mockup of the way you see the feature looking, before implementing it. This can mean either just putting buttons etc. on the page in dev, or using your browser devtools to modify the html on the fly to make a screenshot. Whatever works best for you
suvid[m] uploaded an image: (62KiB) < https://matrix.chatbrainz.org/_matrix/media/v3/download/matrix.org/flzKMOtCxabUkwpopzPWIMEC/image.png >
minimal joined the channel
bitmap[m]
<reosarevok[m]> "bitmap: I tested disabling `$use..." <- a good route would be to print the query from Perl and run it directly on hendrix with `EXPLAIN ANALYZE`
monkey[m]: that actually looks much clearer , you're right!
monkey[m]
Not the one I had in mind and mentioned yesterday, but I found something similar
Jigen
there are still improvements, probably ,but it's definitly better thna the previous!
monkey[m]
👍️
I also changed readthedocs config to automatically build pull requests, meaning contributors can edit docs directly in github and get a preview of their changes without needing to code or run anything on their machine
mayhem: having spent many hours trying to debug issues with building popularity data, it turns out to be a casing issue in the _mbid field. spark doesn't have a uuid type so it treats them as strings. i think we should lowercase all UUIDs when accepting listens in LB automatically, alternatively we need to lowercase them at dumps time or in each query in spark.
mayhem[m]
but we store them in PG which has a UUID type, which I would assume doesn't have a case, right?
lucifer[m]
also, need to fix it for existing listens which is not fun but oh well
we store user submitted listen data (additional_info) as json
mayhem[m]
oh, this is in the JSON field, which doesn't have a UUID type,.
I think we should to both. convert to lower case when ingesting, but also do so when we use them for stats work.
lucifer[m]
doing it when using them for stats work would likely make all query slower.
if we do it ingestion time, i think we should be fine. given that we also fix the listens already ingested.
mayhem[m]
fun. well, we need to add unique ids to the listen table, so might as well do it then
lucifer[m]
yeah, makes sense.
i'll update the popularity queries for now. open a ticket for rest of the stuff.
BobSwift[m] has quit
pite has quit
minimal has quit
TOPIC: MetaBrainz Community and Development channel | MusicBrainz non-development: #musicbrainz | BookBrainz: #bookbrainz | Channel is logged and not empty as it is bridged to IRC; see https://musicbrainz.org/doc/ChatBrainz for details | Agenda: Reviews, Hetzner mainboard repl. (zas)
