#metabrainz

mooooin!

alastairp: #1183 is ready -- sorry that got to be a bit of a big PR. but it cleans a lot of things up and puts us on the right track for mapping work.

hello ruaok

cool, will do

I'll submit a PR for getting typesense into production later. no need to shove that into this PR.

great

this PR feels good, I have to say. feeling like a giant ball of headaches is getting tucked away.

now, do we still need MessyBrainz?

mmm

you said a few things earlier in the week, and I think based on that we still do

only for internal reference, I think. I'm not advocating that we get rid of it, but its utility to us has diminished.

I suspect that at some point later we'll be happy to have it.

I'm not convinced that listen -> typesense -> MB is going to give us everything that we need

and I worry that we'll end up like lfm with a bunch of dodgy mappings

I think it will give us better results than the MSID mapping I had.

> and I worry that we'll end up like lfm with a bunch of dodgy mappings

I hear that loud and clear.

which is why I am going to create a separate table in timescale for keeping the matches

so that it can be dropped and recreated at any time.

so I'm all for putting stuff into messybrainz still and then doing a timesense lookup at import time to get an id

great, I'm all for that, then

agreed. I'm not suggesting that we do anything with MSB yet, it was mostly just a thought.

great. just checking

Mr_Monkey: shall we get your DB running the latest schema?

I'm looking at the planning doc now.

Sure. I'm just starting it up with port exposed, let me have a look and see if I can figure it out

k

> item count (this is a computed field, not in the DB schema)

Mr_Monkey: computed where? in the python code? could/should it be computed in JS?

As I'm writing a bit of python for the `user_name/playlists` route I can definitely say it would be better there to load the playlists without the tracks, and not have to do the computation in JS.

ok

Now, that being said, we could also decide not to show the track count in the playlistS view, but only on single playlist view in which case we can compute in JS

let me make a plan to store the data. we're not committed to using that field.

Now that I think about it, for the single playlist view it'll be better to compute it in JS (since the count will change with addition/deletions and we need to keep track of it anyway)

We could also have a separate endpoint to return a playlist's item count like we do for user's listen count

we should not do that for something that can be computed reasonsably easily.

mm, remind me why we need this field?

from reading the document I understand that it's not in xspf, but we have/want/need it?

the latter point is correct. I'm also with you that it doesn't make sense to store computed values.

though if someone wanted to get just the metadata, without fetching the tracks, then yes.

but our API doesn't support that... yet.

ruaok, alastairp : I think there's a typo in the playlist SQL update script. I'm getting `psql:/tmp/2020-11-21-playlists.sql:29: ERROR: column "copied_from" does not exist` and I think the end of line 29 should read `ON playlist.playlist (copied_from_id);` instead of `ON playlist.playlist (copied_from);` Can you please confirm? I'll commit the change if so.

yes, I changed the name of the field but I must have missed the index

sorry for that Mr_Monkey

Okidoke, will commit.

ruaok: right, I guess I'm asking why do we need to send a number which is the length? what's stopping someone from just doing len(tracks) ?

oh, saw your comment about metadata

that's a good point

alastairp: len(tracks) was my point. save for the metadata bit.

I'll add a field in the spec, even if we dont use it.

alastairp: There's also some occurences of `copied_from` in some SQL commands in db/playlist.py ; Shall I fix them too?

:( I think so

let me have a quick look at my git log

yeah, any occurrence of copied_from that wasn't changed to _to should be updated

if only I had written tests

👍 It's only two instances, in the same file. Committing.

And pushed

there is the update file, but there are also the files in the create_tables and create_indexes

Those have the correct column name

updated the gist.

alastairp: now that there are two namespaces, I used anchors to differentiate them.

ruaok: sure thing. I'll run this past my semantic web guy

reosarevok: is it bad form to have a wiki page that starts with a lower case?

I think it might be better to do it as a path, because then in the definition document you can make the fields available at the anchor

Dunno? :D

Wait, you mean the title or the content?

reosarevok: https://musicbrainz.org/doc/libcoverart nope.

:)

IIRC some older versions of mediawiki didn't allow that but now they do?

I need to put docs on this page: `https://musicbrainz.org/doc/jspf#playlist`

Oh, it's some https://www.mediawiki.org/wiki/Manual:$wgCapita...

So it's just a setup thing, where you can start with lowercase but then it won't redirect to it from uppercase or something?

Anyway, it should work fine I think

Just make a jspf page

thx.

do you happen to know how to make an anchor?

is that just heading?

== Achors ==

+n

so it appears.

Yeah, IIRC it is

Although if you want to make sure the link is long-lasting, you better set this page for transclusion too, so that one of us needs to allow changes to it :)

(the link to /doc/ anyway, I guess a link to the wiki would always have that risk)

that's the plan.

Ok

alastairp: https://musicbrainz.org/doc/jspf

all proper semantic web and shit. :)

Noice

does all that make sense, Mr_Monkey ? cover all your needs?

Yes, I think that'll do nicely !

great.

In the meantime I've made some progress with the flask view endpoints.

Still need to implement that new structure with extensions in the React code and we should be set !

I've already been able to create a playlist from the front-end page, so we're in business

We're missing a couple of endpoints for playlists (edit, copy), but it looks like it'll be easy to add.

yes, those should be quick to do .

speaking of which, lets pick a day next week to hack on the playlist stuff, shall we?

wed?

🤣

wednesday seems fine to me

Can do wednesday

into the calendar it goes.

Ditto.

Ah, there's on more field needed in the playlist JSPF extension ruaok : `last_modified_at`

Mr_Monkey: https://musicbrainz.org/doc/jspf

Ah, sorry, I was looking at the gist …

I did just add it to the web page. let me add a link to the web page in lieu of the gist.

done.

ruaok, alastairp sorry to disturb you again, I've got a python issue I don't know how to fix: `ujson.dump` doesn't like the output of `serialize_jspf`: `UnicodeDecodeError: 'utf-8' codec can't decode byte 0x9a in position 83: invalid start byte`