bitmap: ruaok: bono was slow probably because its running a dev instance. in dev, the js files are almost ~10 MB each. in prod, those are shrunk down to ~800 kb each + plus get cached.
2021-10-13 28651, 2021
bitmap
right, I figured they just weren't minifed
2021-10-13 28625, 2021
bitmap
MB's are probably >10 MB in dev if you include source maps, though we output those to a separate file
2021-10-13 28616, 2021
lucifer
makes sense
2021-10-13 28639, 2021
lucifer
btw MB is using ES5 or ES6?
2021-10-13 28623, 2021
bitmap
we compile everything to es5
2021-10-13 28637, 2021
bitmap
in the actual source code we use stuff from es2020 afaik
2021-10-13 28642, 2021
lucifer
ah nice
2021-10-13 28649, 2021
peterhil joined the channel
2021-10-13 28633, 2021
akshat
Hi lucifer!
2021-10-13 28647, 2021
lucifer
hi!
2021-10-13 28614, 2021
akshat
So to be able to run the color browse branch locally, I would have to use port forwarding to bono.meb?
2021-10-13 28639, 2021
akshat
Or how does the steps go?
2021-10-13 28600, 2021
akshat
do^
2021-10-13 28614, 2021
lucifer
you can bring up an instance on bono.meb. and then access it using the public url.
2021-10-13 28635, 2021
akshat
Okay understood. How do I bring up the instance?
2021-10-13 28647, 2021
lucifer
./develop.sh up
2021-10-13 28624, 2021
akshat
But that starts it in localhost, right?
2021-10-13 28632, 2021
akshat
How do I bring it up in bono?
2021-10-13 28636, 2021
lucifer
you'll probably get an error currently, because my containers are up. i'll take those down.
2021-10-13 28627, 2021
lucifer
run it on bono. i mean ssh bono.metabrainz.org, git clone lb server, checkout branch, run ./develop.sh up.
2021-10-13 28647, 2021
akshat
Interesting so I wasn't cloning the project in bono to do stuff. Got it
2021-10-13 28623, 2021
akshat
What I was thinking was that I could mirror my local work to bono somehow and access the stuff there. But I will have to setup everything in bono again right
2021-10-13 28631, 2021
akshat
Great, I see it's already allocated.
2021-10-13 28643, 2021
akshat
You must be using it I suppose
2021-10-13 28648, 2021
lucifer
it might be possible to mirror your setup but don't think it will be easier than manually copying.
2021-10-13 28620, 2021
lucifer
yes i'll bring mine down
2021-10-13 28611, 2021
akshat
Thanks
2021-10-13 28627, 2021
lucifer
done
2021-10-13 28621, 2021
akshat
"ERROR: for web Cannot start service web: driver failed programming external connectivity on endpoint listenbrainz_web_1 (dc64de3e4658e87683554047ac592dec4a1ba603a6a86a231d35485d0c6e5b1a): Bind for 0.0.0.0:80 failed: port is already allocated"
2021-10-13 28625, 2021
akshat
Still do see this
2021-10-13 28631, 2021
lucifer
which branch?
2021-10-13 28653, 2021
akshat
color browse only
2021-10-13 28613, 2021
lucifer
let me check, it had the workaround until yesterday
outsidecontext, rdswift: I was told that https://picard-docs.musicbrainz.org/en/variables/… is a bit outdated and the relevant checkbox is now "Enable track relationships". If so, can we update it? :)
2021-10-13 28609, 2021
reosarevok
outsidecontext, zas: in a related question, does Picard have any way currently to get relationship data for releases that go over the 500 recording limit? We really should figure out a way of doing that - if it needs a new endpoint we could talk about it with bitmap and yvanzo.
2021-10-13 28637, 2021
reosarevok
(without that, the payoff for people actually improving the data on huge releases is super low :) )
2021-10-13 28636, 2021
zas
afaik Picard doesn't do anything special, and depends on the web service to provide data, if it is limited server-side, then Picard can't rely go over that. Now I'm not sure what's this 500 recordings limit. I wish we had ws "paging", and no limit at all.
2021-10-13 28617, 2021
outsidecontext
Yes, that's limited server side. The only way around would be currently to load the data piece by piece afterwards, probably per recording. That was proposed before, but it obviously would be super slow (8+ minutes with the 1 request per second limit)
2021-10-13 28613, 2021
outsidecontext
So that's mostly a server side issue. Having the ability to get the recording data for a release paginated would be a way around that I guess, e.g. if the endpoint only returns 500 recordings per call. Even for most huge release it would still be only 2 or 3 calls I guess
2021-10-13 28609, 2021
aerozol joined the channel
2021-10-13 28630, 2021
Etua joined the channel
2021-10-13 28634, 2021
Etua has quit
2021-10-13 28610, 2021
reosarevok
Yeah, an option I could see is having a special endpoint that returns just relationship data for the recordings/works, given a release MBID
2021-10-13 28616, 2021
reosarevok
I guess that's kinda what you were suggesting :)
2021-10-13 28659, 2021
reosarevok
I wanted to make sure Picard didn't currently implement a "check every recording" option or anything
2021-10-13 28605, 2021
reosarevok
But yeah, I guess that'd be super annoyingly slow
2021-10-13 28633, 2021
reosarevok
bitmap: I'd really like some feedback on this when you're around ^ :)
2021-10-13 28629, 2021
outsidecontext
reosarevok: not sure about that, if the endpoint loading release data with many recordings + works and their relationships is slow a separate endpoint for loading the recordings + works and their relationships will likely just suffer from the same issue. As I understand the problem with loading the release is really the data on recording and work level
2021-10-13 28642, 2021
reosarevok
I meant, having that paginated
2021-10-13 28600, 2021
reosarevok
So you get the recordings without rels in the normal request (with *some* notification that rels were not returned)
2021-10-13 28609, 2021
outsidecontext
Yes, makes sense
2021-10-13 28618, 2021
reosarevok
And then you can get a paginated endpoint that is just recordingmbid: rels data somehow
MBS-3680: Error 502 Bad Gateway loading certain releases from the webservice
2021-10-13 28633, 2021
ROpdebee has quit
2021-10-13 28645, 2021
opal has quit
2021-10-13 28612, 2021
tandy[m] has quit
2021-10-13 28613, 2021
legoktm[m] has quit
2021-10-13 28613, 2021
leonardo has quit
2021-10-13 28613, 2021
yvanzo has quit
2021-10-13 28655, 2021
mruszczyk has quit
2021-10-13 28655, 2021
milkii has quit
2021-10-13 28655, 2021
Rotab has quit
2021-10-13 28656, 2021
atj has quit
2021-10-13 28600, 2021
yvanzo joined the channel
2021-10-13 28648, 2021
tandy[m] joined the channel
2021-10-13 28648, 2021
legoktm[m] joined the channel
2021-10-13 28648, 2021
leonardo joined the channel
2021-10-13 28638, 2021
riksucks has quit
2021-10-13 28654, 2021
riksucks joined the channel
2021-10-13 28601, 2021
ruaok
moin!
2021-10-13 28622, 2021
ruaok
the bot got 55k images indexed before getting a 403 axe.
2021-10-13 28658, 2021
zas
about handling of huge releases, I guess bitmap has few ideas. This is something we could discuss during the summit. It seems to me that will be more and more a problem since we get more and more metadata.
2021-10-13 28649, 2021
ruaok
zas, bitmap : thanks for the CAA setup. working great. now running with 16 threads.
2021-10-13 28611, 2021
ruaok
patton at less than 20% cpu.
2021-10-13 28643, 2021
zas
ax51 are real workhorses
2021-10-13 28612, 2021
ruaok
I love the AMD cpus. I have one on my desk at works and its lovely.
