#metabrainz

mayhem: i see. so crawl albums, discover artists from tracks and query their albums and add it to queue?

reosarevok: have you tried listening to music by people with only real characters in their name?

lucifer: yep!

makes sense, so we'll need to maintain 2 sets. one for artist ids and one for album ids.

a-zA-Z0-9 of course :)

two sets of internal queues? yes.

1 queue should suffice i think. for artist we only need a set.

yeah

ansh do we have any examples where there is a relationship of 1 author -> 2 artists? (or the other way around)

I think I discussed this with monkey a bit and we came up with some cases where it might make sense, but we don't know any concrete examples

ansh: I'm just looking at this with monkey now, in the office

alastairp: I found some such cases in the database. I'll find them again

the one thing that we both saw at first is that the 3 sections (list of reviews, list of this entity in the other db, list of related entities) are difficult to visually separate

I think the best solution here would be to add some more whitespace and open a ticket for aerozol to make it look better

Yes, that would fix the issue for now

I'm going to open a ticket

for now let's not overthink it, and just add some more whitespace, and leave it as-is

so that we can merge it

yvanzo: hi! I want to do a push for updating translations on CB after all of ansh's work. should we remain with transifex for now?

this is what monkey and I just prototyped

in this case, the "this entity also appears" is currently in the table, as `<tr><td colspan=3></td></tr>`

rather than your version which has a separate table per list of reviews

and it also explicitly says "no reviews" in the case there aren't any, which was one of the things that made the earlier Ann Leckie example a bit confusing as to where each section starts and ends

one thing we're not sure about is what it will look like if a) the main entity you are viewing has no reviews, but a related one does, or b) none of the main entity or related entities have reviews

^what he said

It turns out we're too smart for our own good and your way of doing is is both simpler and more future-proof (with the CB-442 redesign we will soon lose the table elements)

CB-442: Improve layout of CB entity page https://tickets.metabrainz.org/browse/CB-442

Lesson of the day: don't over-engineer

[musicbrainz-server] 14mwiencek merged pull request #2582 (03master…relationship-editor-react): Convert the relationship editors to React https://github.com/metabrainz/musicbrainz-serve...

reosarevok: Your track example was really great. I just discovered that there is an undocumented limit to the size of the query parameter sent to the Spotify API which if reached results in a 404

144 characters max

hah!

mayhem: deployed the album crawler and surprisingly. nothing pending...

so if i listed to stuff now it should start crawling them?

huh, but listens should come in and start causing items to be downloaded. but that hasn't happened in a few minutes, so something seems off.

even before i took it off, the artist id crawler only had 1/2 ids in pending

for approx ~30 mins or so.

ok, I guess it fetches everything and then goes back to sleep.

maybe print out how many albums have been fetched since start?

can see that in redis.

118 so far in 5 mins

question: if you find an artist id, do you automatically download all albums for that artist?

and also then add new artist ids to the queue?

add album ids for incoming listens to queue.

then discover albums from tracks artists.

looks about right. odd.

let add more stats about albums fetched, artist/album ids discovered, etc.

🤦

oh?

I think I hat a bug on LB; the msid of the last couple of tracks (by DJ Python) aren't resolved correctly on https://listenbrainz.org/user/heyarne/, even though https://labs.api.listenbrainz.org/explain-mbid-... looks fine?

They are properly linked to their MB entries (i.e. resolved?) while playing, but as soon as they appear in the list on the left not anymore

Should I open a bug report?

let lucifer take a look at it -- he's more up on the current idiosyncrasies of the mapper.

mayhem: https://github.com/metabrainz/listenbrainz-serv...

duh

working fine now

lol

great, good output!

this is already getting stored in grafana as well, if you want to graph it

oh well, the fanout setup is wrong which broke the mapper.

heyarne[m], thanks for the report. will fix.

🌄 amazing

mayhem: my understanding of fanout messages was incomplete. we can reuse the exchange but still need a unique name for this queue to ensure both the mapper and the cache get the listens. "spotify_metadata" for a new queue name?

heyarne[m]: can you try listening to that song again and see if it gets mapped now?

[musicbrainz-server] 14mwiencek merged pull request #2603 (03master…import-sort): Eslint: autosort imports by path https://github.com/metabrainz/musicbrainz-serve...

alastairp: monkey: I think keeping white spaces would be good for now. The prototype looks good, but I am also not fully sure for those two cases. Because if there are no reviews for the main entity, It would be kinda unclear for the users

Should we say 'No reviews' for the related entities btw?

<lucifer> "heyarne: can you try listening..." <- Yup! That was fast

awesome!

lucifer: that sounds fine to me.

`Pending IDs in Queue: 211652`

oy, that is clearly working ok.

mayhem: yeah but something still seems off, 2000 ids in 30 mins is clearly too slow.

alastairp: do you have a current email for Paul Lamere?

fetched or discovered ids?

fetched

mayhem: the only one I have in my inbox is @echonest.com, which I suspect no longer exists

discovered is > 200k

alastairp: ok, I'll dm him on twitter, that should work.

not sure what the rate limits are lucifer, so not sure.

are we fetching one album at a time or multiples at a time?

1 album at a time.

there is an endpoint for fetching multiples in one call -- lets use that.

hmm which one?

https://developer.spotify.com/console/get-sever... ?

yep

(beat me to it)

this does not accept a limit variable as far as i can see so not sure if it'll cut off tracks.

do you know some long albums so that we can test?

I don't, but reosarevok does

Long as in many many tracks?

reosarevok: yes

Hmm

> 50 tracks to be specific

uh. i mean more than 50 tracks

lucifer: https://open.spotify.com/album/1wkBOaFQVTg1mN4W...

reosarevok: thanks

mayhem: yes, tracks are cut off after 50. i guess we could detect and do separate queries in that case though.

Yes, a pita, but bound to be faster.

loujine, jesus2099 (and probably most other userscript makers): the new React relationship editors are out in beta. They'll be there for a while (longer than the usual week)

They'll almost certainly break several of your scripts - feel free to ask bitmap or me if you need help with something (well, bitmap knows a lot more since it's his code, but I can try to help)

[musicbrainz-server] 14reosarevok opened pull request #2636 (03master…MBS-12205): MBS-12205: Add "play on ListenBrainz" button https://github.com/metabrainz/musicbrainz-serve...

mayhem, monkey ^ (seems to work, anyway)

Given LB has MB database access, though, wouldn't it be nice to just give it a collection ID instead and it would build the playlist from the DB? :p

The current way is kinda hackish and is limited to the first page of results

(for large collections)

mayhem: added batches but that doesn't seem faster either.

lol https://twitter.com/chhopsky/status/15699239467...

Aheno: thanks! I did see, I'm just recovering from a little collection of injury and illness. But should get onto it today

Also fair warning - everything here usually moves at a slow pace. So I would get used to playing the loong game. And doing a lot of editing/scanning while you wait!

lucifer: oh heh, lol. we'll we'll find out soon enough why it is slow.