#metabrainz

It is unknown whether the tmp file location changes would cause any decrease, but if it does it would be due to the underlying filesystem, thus more a deployment issue.

The ionice stuff doesn’t seem to work at the moment, possibly due to a deployment issue too. It is unknown how much effect it would have really either.

By “deployment issue” I mean something external to MBS such as cgroup driver.

ok, makes sense

"Allow specifying the path to temporary directory" seems generally useful but we can probably scrap the rest

Alright, I will shrink this PR and attach the scrapped part to the ticket just in case, thanks for looking into it.

👍 thanks for all your work on it

mayhem: spotify export still fails for me when using tag radio, i'll look into again.

thanks!

bitmap: On a related topic: the alert about disk space usage during weekly cron jobs; Are there some archives we could rotate to a different volume/host? For example JSON dumps on a yearly basis?

yvanzo: yes, we could probably do with archiving incremental json dumps (and maybe replication packets) more than a year old back onto aretha

lucifer: not sure what this means but this cert thing is not allowing lb login below api level 25 in android https://usercontent.irccloud-cdn.com/file/zFwkR...

jasje: i think if you download chrome or firefox it will work on api level below 25 too

lucifer: but then we can't parse the html to get token

yvanzo: moving the incremental json dumps would be a lot more impactful to start with, anyway, since they take up a lot more space

So it bricks login on api 25 and below

Should I bypass the error then?

jasje: use chrome webview?

lucifer: https://www.irccloud.com/pastebin/GBeoxPPw/

lucifer: thats new

jasje: bypass it conditionally.

if the error is on API 24 or low, ignore.

jasje: there's probably a compat version available.

this is something that we can't really control, so add a comment and ignore the error if it works.

alright so bypass it api 24 and below?

yes

because thats the only affected are

area

okeys

bitmap: Updated the PR about temporary directories.

thank you

yvanzo: btw, here's the first query that was logged as killed during yesterday's OOM event https://gist.github.com/mwiencek/300eb511938870...

bitmap: that’s me ^

I don't'recognize the query as being from MBS. (also not certain if this was what actually triggered the event)

I’m setting up a replica with edit data on wolf as a fallback.

alright

if it is problematic we might need some new indexes for it

[musicbrainz-server] 14yvanzo merged pull request #2350 (03master…lower-dump-io-load): Refactor handling temporary directories (related to MBS-12538) https://github.com/metabrainz/musicbrainz-serve...

the query is intended to find examples for https://github.com/metabrainz/musicbrainz-serve...

[musicbrainz-server] 14yvanzo closed pull request #2731 (03master…central-entity): MBS-12552 (IV): Define central entity https://github.com/metabrainz/musicbrainz-serve...

bitmap: Does this focus ring remind something to you? https://github.com/metabrainz/musicbrainz-serve...

(2010)

heh, I left a comment already before I saw your ping

but no, it does not

[musicbrainz-server] 14yvanzo merged pull request #3005 (03master…a_focus): MBS-11947: Stop hiding focus indicators on links https://github.com/metabrainz/musicbrainz-serve...

[listenbrainz-android] 14dependabot[bot] opened pull request #211 (03main…dependabot/gradle/androidx.preference-preference-ktx-1.2.1): Bump androidx.preference:preference-ktx from 1.2.0 to 1.2.1 https://github.com/metabrainz/listenbrainz-andr...

[listenbrainz-android] 14dependabot[bot] opened pull request #212 (03main…dependabot/gradle/navigationVersion-2.7.0): Bump navigationVersion from 2.6.0 to 2.7.0 https://github.com/metabrainz/listenbrainz-andr...

[listenbrainz-android] 14akshaaatt merged pull request #199 (03main…dependabot/gradle/hilt_version-2.47): Bump hilt_version from 2.46.1 to 2.47 https://github.com/metabrainz/listenbrainz-andr...

[listenbrainz-android] 14akshaaatt merged pull request #195 (03main…dependabot/gradle/exoplayer_version-2.19.0): Bump exoplayer_version from 2.18.7 to 2.19.0 https://github.com/metabrainz/listenbrainz-andr...

[listenbrainz-android] 14akshaaatt merged pull request #210 (03main…dependabot/gradle/io.sentry.android.gradle-3.12.0): Bump io.sentry.android.gradle from 3.11.1 to 3.12.0 https://github.com/metabrainz/listenbrainz-andr...

[listenbrainz-android] 14akshaaatt merged pull request #208 (03main…dependabot/gradle/androidx.paging-paging-runtime-ktx-3.2.0): Bump androidx.paging:paging-runtime-ktx from 3.1.1 to 3.2.0 https://github.com/metabrainz/listenbrainz-andr...

Dude jasje, the Feed looks INSANELY good in the app! Wow! 🔥🔥🔥🔥

Glad you liked it!

Stuff is as reusable as it can be

The best thing we’ve had in the app so far for me

Heh there's alot more to come

im thinking of doing notifications after gsoc

that would just complete it all

i recommend a song to you, pop! there's a notification

Killer ⚡️🔥

Can’t wait to have this jn beta

Me too!!

bitmap: thanks for your time, off for a meal

same and likewise :)

lucifer: https://stackoverflow.com/questions/7416096/and...

read the comments of first reply

i don't think ignore ssl error is a good idea

ignoring*

Itll put the app's reputation at risk

akshaaatt^

[listenbrainz-android] 14akshaaatt merged pull request #211 (03main…dependabot/gradle/androidx.preference-preference-ktx-1.2.1): Bump androidx.preference:preference-ktx from 1.2.0 to 1.2.1 https://github.com/metabrainz/listenbrainz-andr...

What’s the problem with using this solution https://stackoverflow.com/a/49786820 , jasje?

That violates google's policy

[listenbrainz-android] 14akshaaatt merged pull request #207 (03feed…feed-section-phase-2.1): MOBILE-138: Feed Section Phase 2.1 https://github.com/metabrainz/listenbrainz-andr...

because showing info about ssl errors in web view is just not it for them

They say the user can't make an informed decision

[listenbrainz-android] 14akshaaatt merged pull request #205 (03main…dependabot/gradle/org.jetbrains.kotlinx-kotlinx-coroutines-test-1.7.3): Bump org.jetbrains.kotlinx:kotlinx-coroutines-test from 1.7.1 to 1.7.3 https://github.com/metabrainz/listenbrainz-andr...

Plus we really don't want to risk the popularity on playstore

[listenbrainz-android] 14akshaaatt closed pull request #48 (03main…benchmark-jasje): Initialized benchmarking https://github.com/metabrainz/listenbrainz-andr...

Prolly bring back the old login screen and throw in mix of if else imo

[listenbrainz-android] 14akshaaatt merged pull request #200 (03main…dependabot/gradle/com.airbnb.android-lottie-compose-6.1.0): Bump com.airbnb.android:lottie-compose from 6.0.1 to 6.1.0 https://github.com/metabrainz/listenbrainz-andr...

[listenbrainz-android] 14akshaaatt merged pull request #201 (03main…dependabot/gradle/com.airbnb.android-lottie-6.1.0): Bump com.airbnb.android:lottie from 6.0.1 to 6.1.0 https://github.com/metabrainz/listenbrainz-andr...

[listenbrainz-server] 14amCap1712 merged pull request #2536 (03master…refactor-handlers): Refactor spark handlers https://github.com/metabrainz/listenbrainz-serv...

mayhem, arsh: https://test-api.listenbrainz.org/1/popularity/...

hmmm. duplicates in the data.

different recordings, but same names. does the data need to be canonicalized before going into this process?

where?

row 0, row 1

hmm those are different for me

oh, sorry. that's the album. ignore me.

ah cool

this MLHD+ dataset so the dataset is already canonicalized.

arsh: you can use the fields in that to get coverart like this: https://github.com/metabrainz/listenbrainz-serv...

yes, looks great!

!m lucifer

You're doing good work, lucifer!

just use `caa_release_mbid` instead of `release_mbid`

mayhem: i am not sure why but tag radio picks standalone recordings even when the non-standalone versions are available.

any ideas why?

troi does very little for the tag radio. I literally just choose a section and then randomly pick recordings.

if the recordings that I am picking are bad, its because they came that way from the tag query.

i see what exactly happens when we just use an artist seed?

the top recordings for artists, the old one, is used for the seed artists and its similar artists.

still using this one: https://datasets.listenbrainz.org/popular-recor...

I need to switch to the new popularity endpoint

that is weird.

iirc we removed standalone recordings from MLHD+ dataset

but https://datasets.listenbrainz.org/popular-recor... has 0190599f-c7fe-4afb-8ef8-731857f34b45

seems that "it happens randomly" can't possibly be the answer, can it?

sure it can be but that means the dataset generating script had a bug and we'll have to generate this from scratch

not the popularity data, MLHD+ itself.

yeah.

wait is the MHLD+ data part of the tag query results?

Thanks lucifer: I will take a look

the tag data comes from MB, no?

do you exclude standalone recordings from the tag queries?

mayhem: the tag data comes from MB, MLHD+ data is part of that as in it is used to order the tags based on popularity.

ok, order, but not a data source.

nope i don't exclude standalone recs from tags queries because those shuoldn't be in the dataset in the first place.

if the MLHD is used to order, but not as a data source, then this could be the problem, no?

sorry not sure what you mean?

but yes in general standalone recording are a problem, regardless of how those come into LB.

the recording_mbids come from MB tag data queries... tagged recordings. yes?

anything mapping related will break when it encounters a standalone recording mbid.

and then those tagged recordings are ordered by MLHD+ data. but is recording_mbids taken from MHLD+?

recording mbids are from MB only.

for tags dataset

yes, and if the standalone recording MBIDs are not filtered out, then they get returned as part of the tag query no?

yes

but this popularity dataset (https://datasets.listenbrainz.org/popular-recor...) is only from MLHD+ data.

it also has standalone recording MBIDs

ok, so there is the source of standalone recordings then. unless I am too tired to understand. in which case we should continue tomorrow.

yes that is right.

just to clarify, we have multiple sources of standalone recordings.

regardless of whether we redo the dataset, we'll need to handle this in LB better.

oh, I think i understand what you are saying. you're saying it doesn't happen on artist, but it happens on tag, even though they are fed from the same data. is that it?

uh no, i am saying it can happen on both.

that is what I was trying to say.

now, what I should try is switch the artist source to the new popularity dataset.

then then problem might start appearing in the artist source of lb radio. then it would make sense, and somehow the old popularity data set had no standalone recordings.

i see makes sense.