#metabrainz

shivam-kapila: pong

shivam-kapila: I read that you have a PR on Brainzplayer. Can you explain me in brief what functionality you plan to add in there?

:)

pristine___: didnt get ya

shivam-kapila: what are you working at in Brainzplayer?

Just changing its look

Anything in your mind

shivam-kapila: ah. Cool. Not really, was just checking if you are doing anything in the backend.

iliekcomputers: ruaok: Do we have a global/admin LB Spotify access token

and API key or a playnback key?

just a KEY for search

CoverArts

to*

I am currently using user's token but that wont work if the user hasnt connected Spotfiy

if we have one for production, you shouldn't be using it. make yourself one at developer.spotify.com

yes I am using mine

I mean can I change my code to use that in prod

shivam-kapila: we wouldn't want to expose an API key on the frontend anyways, btw.

the user's client secrets are only exposed when they're logged in.

iliekcomputers: Right. Can you tell me then how should I be fetching coverarts

youtube API also needs access token

shivam-kapila: CAA?

coverartarchive seems the way to go

But we dont have much data in CAA

it also adds an incentive for people to add covers to coverartarchive

if there's no coverart, link them to a page which allows them to add the art

So CAA? getCAA(): loadNoCoverArtPhoto()?

with link, yes

and what should that link be in your opinion

MB home page?

I mean add data page

one more option maybe routing through the backend?

ishaanshah: Sorry didnt get you

Can you elaborate

like write an endpoint to fetch coverart url from spotify

and use that in the code

then we dont expose the API key

and that uses our backend key

yeah exactly

oh that will be a very nice idea

maybe even have some primitive caching mechanism

Spotify gives a coverart in 99.99% cases

I am gonna cache the data afterwards

there is the risk of making the page slow.

iliekcomputers: I dont render the coverart in the starting itself

i'd prefer to use coverartarchive just to reduce our dependency on spotify, not sure what ruaok thinks

I'd like that too.

I have added the logic in componentDidMount() so that the coverarts cn be fetched after that component loaded

however... loading them from the archive directly is a poor user experience.

ideally there could be a cache.

oh

I'm open for suggestions.

how does spotify cover art work?

ishaanshah: Sorry again didnt get you

I mean you get an URL right?

not the image itself

yes

and CAA the same?

we get a url in CAA too

Then the speed will be same, no?

we should definitely make it as generic as possible, so that it's easy to plug in different sources as backups

and are we allowed to store the links to the images in our DB?

not the image itself just the link

I proposed it way back and then ruaok suggested we shouldnt do so just for the sake of simplicity

storing links is fine.

iliekcomputers: +10

what I was thinking was we have a table in the DB linking MBID to coverart link

and expose it via endpoint

We can already get a coverart using MBID

also allow POSTing to this endpoint so that we can send multiple items

I am up for makinng the solution generic but I will need some opinions on this thing

> we should definitely make it as generic as possible, so that it's easy to plug in different sources as backups

I was talking about this

LB-701

LB-701: My listen page is almost empty https://tickets.metabrainz.org/browse/LB-701

this way we can have multiple sources

I mean we can add the url during imports

in additional_info

but what for the data already present

ok, what I was thinking was, we do something similar to the artist map thing

in the beginning the DB will be empty

now when I make a request, by MBID or MSID

I lookup for the image in spotify, CAA...

store the link in the DB

next time the retrieval will be faster

this way we get both speed and generic data sources

I am not sure about the identifier, i.e MBID or MSID

or simply the release name

ew can make request via recording_msid and user_name

ew*

as the fields

or just recording_msid

wait I will list down the steps

ishaanshah: I am not worried about fetching the links -- that is generally easy.

it loading images from the archive that is slow and very error prone.

+1

ohh, so the archive is the problem?

yes.

ohk

which is why an cache would solve the problem.

but we can't host such a thing.

hmm, got it

we still can use spotify through the backend though

that seems the best way around here

I think we should rely on spotify for now, and the CAA when we can't get an image from the IA.

make the system modular and then improve on as we can.

but given the time constraints for GSoC and shivam-kapila's insane schedule, lets just use spotify cover art.

does this sound good for now?

yep, looks good to me

ruaok: iliekcomputers: you??

which DB??

Timescale