yvanzo, The issue is settint that variable by default binds the container to 443 which it can't do because the reverse proxy does that
2020-11-09 31427, 2020
Lartza
*setting
2020-11-09 31416, 2020
Lartza
So I had to set MUSICBRAINZ_WEB_SERVER_PORT to 443 while changing https://github.com/metabrainz/musicbrainz-docker/… to not bind to that port, and that still seems to make the MB server listen on 5000 but now creates correct urls for the static resources
2020-11-09 31437, 2020
Lartza
I think the experience is in the end a bit better than years ago one you know what is going on :P
this looks like a dodgy result, but is actually correct.
2020-11-09 31407, 2020
D4RK-PH0ENiX joined the channel
2020-11-09 31416, 2020
ruaok
correct as per design of the ACRP-year project.
2020-11-09 31435, 2020
ruaok
(albums are classified higher than soundtracks)
2020-11-09 31435, 2020
alastairp
how can we test this? Does it make sense to get people to do a manual check of a handful of artist/recordings?
2020-11-09 31426, 2020
ruaok
the mapping has tests, we can add more there.
2020-11-09 31427, 2020
ruaok
but I am getting ready to revamp the mapping... I'm still not 100% how to proceed with it, but I want to improve things just yet. I'll need to do some exploratory coding to finally know where to go.
2020-11-09 31410, 2020
ruaok
maybe soundtracks need to be rated higher in my query.
2020-11-09 31455, 2020
sumedh joined the channel
2020-11-09 31419, 2020
reosarevok
ruaok: I'd argue soundtracks should be weighted the same as albums
2020-11-09 31429, 2020
loujine
looks like /ws/2/release doesn't really fetch the quality attribute, I always see "normal"
Because either something was released earlier in a soundtrack (and then that's what you'll often care about) or it was compiled later into a soundtrack (and then it's not the earliest either way)
2020-11-09 31453, 2020
loujine
I'll open a ticket
2020-11-09 31429, 2020
reosarevok
You could argue the same is true for singles and EPs, if you don't count that rn
2020-11-09 31447, 2020
ruaok
sadly this gets into the weeds pretty quickly. I'll consider this for future improvements. but the soundtrack issue makes sense. not sure how to make that work, but....
but for this use case, we're actually starting with data that came from MB.
2020-11-09 31412, 2020
ruaok
meaning that we have known recording with name and artist credit as spelled in MB.
2020-11-09 31422, 2020
ruaok
and we're just asking what was the earliest release for this.
2020-11-09 31445, 2020
reosarevok
Oh, ok
2020-11-09 31457, 2020
ruaok
so exact spelling is an ok requirement here.
2020-11-09 31401, 2020
ruaok
(not for the mapping)
2020-11-09 31438, 2020
reosarevok
It's still likely to fail on something that had "prodigy" at first but now you got a "the prodigy" recording or something, but that's an edge case for now
2020-11-09 31451, 2020
reosarevok
(and those should probably be merged in most cases anyway so)
2020-11-09 31413, 2020
ruaok
well, so the way this data will be used will be:
2020-11-09 31420, 2020
ruaok
1. Get some data to work on.
2020-11-09 31443, 2020
ruaok
2. Lookup actual recordings in MB, more or less from live DB. not found? toss it.
2020-11-09 31455, 2020
ruaok
3. Lookup using the data returned from MB to find the year.
2020-11-09 31419, 2020
ruaok
so, that should be ok for the prodigy case. I think.
2020-11-09 31404, 2020
reosarevok
My point was: "user listens to 'song' by 'the artist'" -> it gets mapped by 'song' by 'the artist' in MB (reissued compilation from 2010 or whatever) -> that's the earliest case for 'song' by 'the artist' but ideally you'd want to find 'song' by 'artist' from 1980 or whatnot instead
2020-11-09 31416, 2020
reosarevok
But really, that's probably skippable for now
2020-11-09 31430, 2020
ruaok
ah yes. that is the mapping's fault. it should map that track to the 1980 version.
