#metabrainz

I think that's even a third topic

oh i am misunderstanding what you meant then.

The two topics at hand: in my feed page, I want to hide other people's recommendations for example, and have that saved in some way so that if i refresh the page they're still hidden

hmm. monkey, I was thinking about generic user preferences a few weeks ago

might be time to bring something like that in

(instead of always adding another column to the user table)

second topic: on my listens page, if I "delete" a listen it will be hidden on the page, but if I refresh the page it'll be showing again.

alastairp: Definitely skirting around the same topic

alastairp: if you'd like to expand on the scope of the idea, feel free to edit the desc.

for 1) do we want the ability for a user to show hidden event again?

👍

I think so lucifer

i see. to confirm i understand the issue correctly, this is like: someone recommended a track and i don't want to see it my feed but only the recommender can delete a recommendation and that too for all so we need a hide button.

Correct

👍

[11:36] <mayhem> two weeks past, two weeks into the future.

honestly I'd let people be able to set the time themselves. personally I don't really apy attention (and lots don't :D) so they might miss this, esp if they don't "follow" a lot of artists, thy might not check often, and if they *do* a lot of artists, things might be lost in the swarm

else i'd leave atleast a couple of months

i think we may need to do some backend redesign to support such events.

Yeah, so storing that on the front-end might be the simple option here

And has the benefit of working for listens pending deletion too

yes, but suppose I login from phone, then it won't be hidden

the device issue still remains then :/.

True. I don't know if that's a major problem, but it's not ideal

+1

for feed events, i think that's a bigger issue because those events are persistent. deleted listens are going to go away in ~1hr so we could probably get away with it.

I think we need a backend for this

honeslt I'd actually have no deadline on it, just show a time line, and show the upcombingmost and latestmost near your *now* and you'll scroll in either direction get further and further "back" or "future"

with some fancy jss/css gadgjet

yeah, i am fine with adding a LB site only endpoint for this. (site only because in the longer run we may want to rearchitect this in case feed page gains more traction)

The drawback of a backend solution is that the way we store event scurrently doesn't allow to store userx X wants to hide event created by user Y

yeah we'll need to add a table for that.

tch

should be doable though and happy to help adding that.

Then again it's not the end of the world, and it does mean we have long term storage

alastairp, mayhem: thoughts?

also I wanted to ask something, what if, I hid a listen that no longer exists

we need to run some sort of checks time to time, to clean stale data from the hiding listens table

And so then when user load their feed page, we also pass in the page props the list of events they chose to hide? Or do we add that metadata to the feed event json?

we could do filtering backend side. only send events that are not hidden to frontend

riksucks: You mean hiding a feed event that then gets deleted? I think that's a non issue, the event just won't be on the feed page anywhere

lucifer: seems good to me.

lucifer: But then how do I unhide it? :p

oh yeah :/

lucifer: are you on support@ ? There is a very odd email that just arrived.

true, but there would be junk in the databse right?

riksucks: that would be easy to clean up from time to time

Very minimal, I'd wager

I see alastairp, so some sort of cron job?

But you could indeed clean up when an event gets deleted

monkey: is this hiding specific events, or all types of events from a user? ("block")

mayhem: nope. you can add me there or forward the mail?

Specific events

mmm

the latter is done, former is coming

👍

monkey: yes, when listens are deleted, we can run check

monkey, then we can pass to frontend in props/api and let frontend handle it.

feed events or listens?

both.

Sorry, that was for riksucks :p

ah ok.

lucifer: added you. have fun reading that. :)

lol looking

if you respond to a user, make sure to copy support@ so we know the issue is resolved.

I wonder if a user wants to hide an event, if they're even interested in getting it back in the future

Agreed lucifer, we can either send a separate list of hidden events, or zip that metadata to the list of events

monkey: ^ or I was just about to also say "and n other hidden events", that you can expand if you want

monkey: afaik, the listens that appear in feed aren't stored in the db as events, the backend just finds listens that should appear in feed and passes it to the client.

alastairp: A good question. That being said, I'm in favor of giving more flexibility

so when a listen is deleted, we can run a check to see if some user has hidden it or not, and delete those entries

Right, gotcha.

alastairp: we were going for a reddit/hackernews style hide button

To be honest, for now I would simply not worry about hiding *listens* in the feed page. We might ultimately not show random listensin the feed page in the future

I see

Since they are pretty transient (reload the page 10 minutes later, get another set of listens) it shouldn't be a big worry

the feed events on the other hand are there to stay on the feed page

right

I see no issue with that personally (but I also won't be mentoring anything back-end related on LB)

sure i guess we could do that.

It's always nice to see extra motivation to do more :)

i or mayhem can mentor the backend stuff as needed/availability.

(depending on what other projects we get)

yes, sounds great. you've already got a feature under your belt, so that is promising.

:D

also mayhem, I wanted to ask something. Do you remember the typesense idea in the missing mb page I once mentioned here?

OK, so to sum up I think we've agreed that we'll be storing hidden feed events and pending-deletion listens on the database rather than the front-end.

yes

We'll probably still want to store some user preferences in the browser, but that's for another day

riksucks: remind me.

Great 👍

I only have love for postgres.

mayhem: so basically there were false positives in the missing mb page. There were songs that were already part of mb but we thought that they weren't. So I had suggested that we could have a typesense searchbox where users can search up the song that already exists

yes, we can do that. it may not be backed by typesense much longer, but we need a general point where we can look up these tracks. it is one of the many projects I'm currently examining and hope to work on in the coming week.

I see. I had some mock ups in mind for the missing mb page, for reporting false positives. If you want, I can show you soon

sure.

there is also a bug report from a user who has found serious problems in adding tracks to playlists, so I think it is important that we get this endpoint right, since it will serve at least 3 different features.

tch

mayhem: did you see the new recs with rank 120?

Hi there! Sorry for the interruption but just making a short self-introduction.

I'm Dijia, now a master student of UCL. My major is integrated machine learning systems.

I'm a fun of music. I like playing musical instruments like guitar and keyboards.

I'm good at python and machine learning but now I hope to do something different.

I'm now learning React by myself and hope to try some front-end tasks.

I'm interested in gsoc tasks of ListenBrainz (as some of them may use both python and react). Hope to contribute to it!

UCL, london?

Yes!

hia Dijia

ok, cool.

hi Dijia, welcome!

which task in particular? I added a pile new ones.

Welcome Dijia !

I'm interested on the "new releases page" one and "Integrate more music services" one.

what music service to you use?

ok, https://wiki.musicbrainz.org/Development/Summer... is now all fluffed up with tasty react projects for 175 hours.

feels much better. thanks for the nudge akshaaatt

So if we're introducing ourselves, I'm finishing high school right before GSoC start, so I'll have plenty of free time. I mostly write Python and am interested in solving the single instance problem of Picard :) I've already assigned a simple task to myself to better understand the code. Hope I'll have both fun and decent experiences, and that our cooperation will be nice. Simply -- hi :>

[musicbrainz-server] 14reosarevok opened pull request #2451 (03master…document-tests-10): Improve test documentation (X): Shared tests (Create) https://github.com/metabrainz/musicbrainz-serve...

Hello skelly37! Welcome to you too !

hi skelly37. zas and outsidecontext would be the people who you should engage with

I've talked a bit with outsidecontext on the tickets page so I think they aknowledged my existence hah

Hey skelly37

Thank you mayhem fot rhw website! I use spotify in UK. And when I'm in China (my home), I mainly use QQ music.

outsidecontext: what about organizing a small meeting to discuss this matter with skelly37 ? In which timezone are you skelly37 ?

'the'

lucifer: Quick feedback without much context: recs pages don't look all that different for me. Top Artists is still 96% a single band, Similar artists is pretty similar result as before (also feels like a lot of the same bands)

zas: I live in Poland, currently it's 12:43PM

ideal timezone then :)

yep, lots of us in that timezone.

or close to it.

Dijia: I think our goal would be to implement apple music next.

do you have a mac/iphone?

Yes!

fantastic :) Also, we're going to switch from UTC +1 to UTC +2 in a few weeks but it's still a small difference, I guess.

and a strong will to live?

lolol, atj

Dijia: then that could work, if you're so inclined. we're very much looking forward to having more music services supported.

ok, running off for some lunch. bbiab!

Apple is transitioning from iTunes purchase/download model to Apple Music streaming model at present

monkey: yeah results have been more or less same for me as well. my top artists tracks are more diverse than yours (have been so most ranks though i thikn).

lots of issues being reported with iTunes APIs

Just to clarify, I'm not complaining at all, just one more user's worth of feedback on the different runs :)