#metabrainz

Morning!

LB question on support: "I was wondering if there is a way to filter my listens by artist, similar to Last.fm. For example, if I wanted to see a chart of my top Nirvana albums. Here's a link to what I'm talking about. https://www.last.fm/user/<username>/libra...;

iliekcomputers, ruaok: not yet? :)

not yet

Ok

Is it planned?

reosarevok: not in the short term

reosarevok: i replied.

Thanks!

Morning!

[musicbrainz-server] reosarevok merged pull request #1626 (master…MBS-11012): MBS-10998 / MBS-11012: Update the WhoSampled and Kickstarter logos https://github.com/metabrainz/musicbrainz-serve...

MBS-11012: Update the Kickstarter logo used in the sidebar https://tickets.metabrainz.org/browse/MBS-11012

MBS-10998: Update the WhoSampled logo used in the sidebar https://tickets.metabrainz.org/browse/MBS-10998

mooooin!

reosarevok: iliekcomputers : I like that we're getting inquiries like that. very promising.

agree

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

heheh, I was just thinking I should review that.

:D

thanks!

also, how much work work it be to re-activate spotify connections for people who had theirs dropped?

I'd really like to fix that inbound data stream.

bitmap, reosarevok: updating test.mb.o with loujine's PR gh:MBS#1578

MBS-10916: showing AcousticBrainz info in the Recording sidebar: https://github.com/metabrainz/musicbrainz-serve...

we have a record_listens field that we could set to true and see what happens.

so, a SQL query?

yeah. to test you could change it for one or two users in https://listenbrainz.org/admin first

to test what happens when the record_listens field is turned to true

I think we ought to follow it up with a PR that tunes the conditions under which a connection is broken

yvanzo: huh, what the actual fuck is going on with that toc link. Will try and figure it out

hmm, i don't remember when we exactly stop recording listens. but yeah, would be worth a look

I thought it would be the TOC id, but it is not

It's also not a real toc though

sigh

yvanzo: that's a medium_cdtoc rowid

reosarevok: this has been reported before iirc

So clearly we need to not call it "toc="

And load the actual toc for seeding

I'll look into it

thanks

Seems like a good break from react :)

But the PR is otherwise fine then? ;p

I did not test preview in release editor

ruaok: the commands we issued yesterday did not run :(

I think you need to restart request consumer. Not sure though

reosarevok: I like guessing games but did not find another way to test that :)

yvanzo: maybe with a real attach link like https://musicbrainz.org/cdtoc/attach?toc=1+9+26... it would work? :)

pristine___: i did run, but got an error: https://gist.github.com/mayhem/79d3b32da2ff78d4...

(if it doesn't, then that's bad :D)

ruaok: yay

I will tell you why

I was, actually waiting for the error

failed successfully, then?

reosarevok: thanks, I will test that

iliekcomputers: I ticked one users box and wait a few minutes. token refreshed, listen imported.

heh

let me review your code, then I'll write a query and have you check it before I run it.

yeah, let's switch them on. see what happens.

yvanzo: I can't find a ticket for that issue, do you remember seeing one?

(if not I can just add it, but :) )

reosarevok: maybe on community or #musicbrainz then

Ok, I'll just add a ticket

[musicbrainz-server] reosarevok merged pull request #1598 (master…MBS-10965): MBS-10965: Convert Add Disc ID edit to React https://github.com/metabrainz/musicbrainz-serve...

MBS-10965: Convert Add Disc ID edit to React https://tickets.metabrainz.org/browse/MBS-10965

Seeding normally would only add it but not actually remove it from the existing release

Possibly we should just disable the "Add a new release" section for /move links honestly

Unless we can think of a way to seed the disc ID, then remove it from the other release, but *only* if the seeded release is actually added and not just cancelled mid-add

maybe this button could be moved to the disc id page

You mean to have a separate "add a new release based on this discid" button?

iliekcomputers: reviewed. so if we restarted redis then we lose the accurate count and be off for 2 days? I can live with that.

Yes but it might not be a good idea actually.

our redis instance is persistent, no?

Disc ID is supposed to match a physical disc. There is no reason for not using Picard to seed a new release with a computed disc ID instead.

but even if not, i'm ok with being off on this data. it can be recalculated anyways.

(Except being a lazy reviewer)

ruaok: so I was checking if our top artist query is correct. It is, as proved by the error. We don't have MBIDs in the mapping for artists listened to by shivam-kapila therefore the join discarded all the artists. I think the error we encountered earlier for Mr_Monkey is related to this. I won't close that ticket since I am not sure about it but I will definitely open a PR to add an exception, warning us about

the unavailability of MBIDs.

yvanzo: yeah, true. I think we should just change the page so that if *moving* rather than attaching, it just hides the usual Add new release section and says "if you want to move this to a new release, please add the release (we can link to a standard release/add there) and reload this page" ?

reviewing the artist mapping is next-next on my list. hopefully we can sort that out this morning.

(spanish morning, not swiss morning. there are 32 minutes and 48 seconds left in the swiss morning.)

considerably more in the spanish morning. )

ruaok: the mapping I was talking about is MBID MSID mapping. I don't think we can do much about it because it depends on the data submitted to Musicbrainz I think

[bookbrainz-site] prabalsingh24 opened pull request #490 (UserCollection…delete-collection-from-ES): Delete collection from Elasticsearch index https://github.com/bookbrainz/bookbrainz-site/p...

> reviewing the artist mapping is next-next on my list. hopefully we can sort that out this morning.

Yes. The join.

oh, so unrelated to the bug you opened yesterdat?

ok

> oh, so unrelated to the bug you opened yesterdat?

have you checked to see if any of the artists that were not matched actually exist in MB?

Yup. The ticket is realted to artist-artist relation

Not the mapping

ok.

because this issue you mention could be two things:

1. The mapping not matching these artists.

2. These artists not existing in MB.

#1 is a problem for me, and that is known.

#2 is an opportunity we can take advantage of.

if you could produce a report that basically states: user X has release Y by artist Z in their top listens, but its not in MB.

then we can publish that on LB and poke users to add those releases to MB. which is something we've been wanting to do for aaaaaages.

Okay. So I checked for the artists MBID on bono using artist MSID. Nothing was returned so I guess it's the second issue.

> if you could produce a report that basically states: user X has release Y by artist Z in their top listens, but its not in MB.

Sounds good.

pristine___: can you pastebin a couple of examples that you didn't find in the mapping? I would like to take a closer look.

A sec

All the artists in here.

I looked up artists using artist MBID.

iliekcomputers: "select count(*) from spotify_auth where record_listens = 'f';" -> 512

MSID*

bitmap, yvanzo: please give opinions/suggestions on MBS-11036 and then I can implement whatever we decide :)

MBS-11036: Move discid -> Add release seeds invalid CDTOC https://tickets.metabrainz.org/browse/MBS-11036

is there any reason for us not to just `update spotify_auth set record_listens = 't' where record_listens = 'f';`

are there conditions where we don't want that?