#metabrainz

reosarevok: https://test.musicbrainz.org/release/f3c0ee8d-e...

(thing I could think of; haveing a medium with tracks and then *removing* them, but it still also works)

removing tracks would be a destructive edit, no?

aw man i hate that

... but you're probably right

you could remove all tracks and then tick the "unknown tracklist" checkbox, i guess

i'm too dumb to login to test anyway :p

just use "mb" aspassport

erh word

naughty

all passwwords are reset to "mb" on test

to aid testing

it's not naughty

so yeah, it works :)

reosarevok: when is barcode and catalog numbers for mediums coming? ;)

ruaok: Can you relate?

I am pretty happy with my results :)

Can someone explain huge loads on trille one can see at https://stats.metabrainz.org/d/000000048/hetzne... ? It has very bad impact on mb website/web service containers response times.

Containers running on trille https://www.irccloud.com/pastebin/LQ5ye7Zc/

very high load (up to 40) happened between 13:50 and 16:00 UTC yesterday and 23:00 and 02:40 last night

yvanzo: see this log https://gist.github.com/anirudhjain75/a3d49412a... Makes it clear here

pristine__: the top artists, those are from collaborative filtering?

iliekcomputers: no

Just the top 20 artists of feb 19.

Ah

Do you plan to run it with the entire data, or is just a recent month intentional?

Also, we have data for May in the cluster now too, I'd be more curious to run it on that.

There is no plan as now since we are not sure how often we will be training the model and generating recommendations.

I can run it with the data of month May and provide you with the results.

SothoTalKer: thanks for volunteering!

SothoTalKer: the report thing sounds reasonable, actually :)

Thanks!

The medium thing, thanks for volunteering :p

iliekcomputers: ^

for May.

SothoTalKer reosarevok, I’d say the report should be in addition to, not instead of. Unless you’re making it so that you can no longer add entirely media‐less releases.

Yeah, I thought in addition to :)

But we should have one

Yep.

Did you ever look at my genre stat ticket?

It’s still not linked to anything anyway.

genre stat !!

+1

:)

good idea

Lotheric: If you have any thoughts: https://tickets.metabrainz.org/browse/MBS-10225

MBS-10225: Add statistics for genre data

voted

I'm very curious to see stats on genres :)

Yep. Me too.

Freso, reosarevok: do we still need that option? I mean when it is implemented you can just tick both boxes "i don't know the medium type" & "i don't know the tracklist":

SothoTalKer: Seems better to leave it out entirely, esp. if you don’t know the amount of media.

If you claim that a release has 1 medium though you don’t know the type or tracklist of, but it really has 4 media…

the checkbox should probably be renamed then, that also the mediums are unknown "The tracklist for this release is currently unknown."

like "mediums & tracklist are unknown"

zas: found unusual entries in mb ws logs.

(i hope it's not me)

yvanzo: zas is busy today. what sorts of weird entries?

ruaok: yup, just replied to him about debug progress :)

ruaok: these ones for example: https://gist.github.com/yvanzo/8a6ae51c5e655b96...

SothoTalKer: that's a fair point, could change it to something like "We have no information about this release's media and tracklist"

Freso: what do you think? :)

Cyna: 'state' should probably not be part of 'Props' in FormRowNameWithGuessCase.js

See root/static/scripts/account/components/EditProfileForm.js for example

[musicbrainz-server] reosarevok merged pull request #1098 (master…MBS-10218): MBS-10218: Fix page param (cover_art -> cover-art) https://github.com/metabrainz/musicbrainz-serve...

MBS-10218: Release page: Cover Art tab not selected / highlit https://tickets.metabrainz.org/browse/MBS-10218

if I want to have the input field value change, I have to pass in state

I'm using hooks withs const so the only way I can get the state is by passing it through props

reosarevok: good enough for me, i guess :)

CatQuest: found 2 typos: 'saluang' and 'violin family' descriptions have </br> instead of <br/>

is it <br/> or <br />?

either way, but </br> is invalid (closing a tag that has not been opened)

i prefer <p></p> anyway :D

[musicbrainz-server] reosarevok merged pull request #1105 (master…MBS-10233): MBS-10233: Use React templates when canceling edit https://github.com/metabrainz/musicbrainz-serve...

MBS-10233: ISE when trying to cancel a "add release annotation" edit https://tickets.metabrainz.org/browse/MBS-10233

reosarevok: you could get it merged to beta aswell, i guess? :x

reosarevok: should the two above be marked as regressions?

SothoTalKer: definitely going to beta today or tomorrow :)

yay

yvanzo: probably :)

oh

not from my phone either, it's broken (warranty expired about 1 month ago) :P

bitmap: Can you help me with the state issue... yvanzo said I shouldn't be passing state as Props

I'm having flow error because of during one of the two types of FormRowSelect. https://gist.github.com/anirudhjain75/a3d49412a...

Cyna: That might be legit after all but it is unclear which component this 'state' relates to.

state comes only from editForm.js

Is there any type definition for this 'state'?

Yes

Its in the Props part of wherever it is used

for example, formRowNameWithGuesscase component

Its causing issue on editForm because FormRowSelect accepts value as both string or number. while the state property that is passed in is either of string or number but not both

Cyna: A temporary workaround could be to enforce annoted type for target.value in onChange parameter given to FormRowSelect calls in EditForm.js

any idea how do I do it... seems confusing to me

with : any

((target.value: any): integer)

((target.value: any): number)

```onChange={(e) => {

const target = e.target;

if (target instanceof HTMLInputElement) {

return setState({

...state,

locale: {

...state.locale,

value: ((target.value: any): number),

},

});

}

return undefined;

Cyna: yup, should do. A definitive fix would be to improve FormRowSelect with parameterized type

This is not supported by flow yet, see https://github.com/facebook/flow/issues/7672

reosarevok: Late but: SGTM.

SothoTalKer: `<br/>` vs. `<br />` is mostly a legacy thing. Any browser from the last 5 (if not more) years should handle either fine. When XHTML was first introduced, many browsers would not understand `<br/>` but would understand `<br />`, so `<br />` was the recommended way for most compatibility. I guess it’s still recommended if you need to support IE 3 or whatever. :)

Probably more like 10 or more years.

XHTML is from 2000, so ~15 or so years or more recent is probably a good estimate. :p

not even *my* browser is *that* old :D