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
*setting
So I had to set MUSICBRAINZ_WEB_SERVER_PORT to 443 while changing https://github.com/metabrainz/musicbrainz-docke... 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
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.
D4RK-PH0ENiX joined the channel
correct as per design of the ACRP-year project.
(albums are classified higher than soundtracks)
alastairp
how can we test this? Does it make sense to get people to do a manual check of a handful of artist/recordings?
ruaok
the mapping has tests, we can add more there.
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.
maybe soundtracks need to be rated higher in my query.
sumedh joined the channel
reosarevok
ruaok: I'd argue soundtracks should be weighted the same as albums
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)
loujine
I'll open a ticket
reosarevok
You could argue the same is true for singles and EPs, if you don't count that rn
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.
meaning that we have known recording with name and artist credit as spelled in MB.
and we're just asking what was the earliest release for this.
reosarevok
Oh, ok
ruaok
so exact spelling is an ok requirement here.
(not for the mapping)
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
(and those should probably be merged in most cases anyway so)
ruaok
well, so the way this data will be used will be:
1. Get some data to work on.
2. Lookup actual recordings in MB, more or less from live DB. not found? toss it.
3. Lookup using the data returned from MB to find the year.
so, that should be ok for the prodigy case. I think.
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
But really, that's probably skippable for now
ruaok
ah yes. that is the mapping's fault. it should map that track to the 1980 version.
