#metabrainz

aerozol: check out MOBILE-107

monkey: Hey!!

Hi jivte

want to discuss abt datetounixtimestamp prop

Sure thing

actually the utility is to to convert the date to unix timestamp

but the prop is required to send timestamp from one component to another

bcz we have date picker in submitlisten component

and the submit listen function is in addlisten component

thats why the prop is necessary

akshaaatt: not much progress since the summit afaik.

mayhem: makes sense to me. is the non-AI approach something we want to do or also an exploratory project for the students??

Right. That touches on my review comment, the timestamp management should be done in the parent component instead and you wouldn't have to pass things back and forth :)

At the moment the logic in submit-listen-info is a bit arbitrarily separated from the modal component rather than having a clear separation of which component needs what information. That's why you end up with having to pass data between children and parent, and for the child to react to props changes in componentDidUpdate.

If you are more comfortable with using react hooks, and functional components, we coudl also try to go that direction

(if that's not the case, forget I said anything :p )

monkey: see the details are in one component but while clearing some buttons are in parent component like that cancel button

or the cross button in modal header so passing data forth and back is necessary

if something else could be done could u plz suggest

[listenbrainz-server] 14MonkeyDo closed pull request #2336 (03master…yim-22-other-fixes): YIM22: coverflow: load lazy image https://github.com/metabrainz/listenbrainz-serv...

moreover we have to keep the component more global thats why made those timestamp prop for use in future

If I'm honest, I think you could bring all the code from submit-listen-info into the add-listen-modal, and get rid of all the things that were made irrelevant by that move. That will simplify the components a lot and remove some hacky react code, and we can from there optimize and make reusable components as we need in the future.

I don't think that's a good idea

:|

bcz that would make a very bulky component

could u give me a day so that I could think of something to optimize the code

rest we would go with moving the whole code to addlisten

If you are aiming for reusability, you will need to reslice your cake according to which part does what functionnally. For example a separate isolated timestamp selection component would make sense, but the submit-listen-info currently does too many different things to be reusable well

why don't we make three more components one for search one for details one for timestamp

what u think?

this would ensure reusability

timestamp component could be used in add album feature

I think that will help the code as it stands to separate concerns.

I am still confused

so what should I do finally now?

If you insist on making separate components, then I would have the following components in the modal:

- track search

- track details

- timestamp selection

As you said

I don't insist but I just want the code to be readable for others too bcz all code in one component is a way too bulky

moreover we only have the problem of passing data through props forth and back

I agree, it'll be more readable with separate components.

but with more components comes more props

again same problem

:|

I'm seeing code that shouldn't be there with the way you are using those props, so there are concerns there with the updating and rendering logic

But separate components will help us isolate the issues

I agree but separate components will make logic too much complex

In short, you shouldn't need to use componentDidUpdate. If you're using it that means the structure of the code is wrong

the only solution to not use componentDidUpdate is moving whole code to addlisten

That's why I suggested that :) It is usually a sign that you are doing logic and state management in the wrong place.

bcz in multiple components too bcz of clearing details componetDidUpdate will be used which is not our need

so then shifting the code to addlisten

will ping you after it is done

:)

I think that will be helpful as a base to figure out what can be easily and conveniently separated into a separate component

Yeah separate components could be refactored later on as you said in the review :)

I think we'll find that for example we can use a ListenCard to display the track details, which is already a separate reusable component

But we'll see about that when we refactor

monkey: should I revert the update of the library back

[listenbrainz-server] 14MonkeyDo closed pull request #2272 (03master…server): Options missing from ListenCard options dropdown https://github.com/metabrainz/listenbrainz-serv...

for playlist PR

LB-#2235

jivte: If you are very comfortable with git then you can try removing those changes from your commit. If not, I wouldn't worry about it too much.

If no worries then no worries for me too

lucifer: Hey!!

need ur help!!

[listenbrainz-server] 14amCap1712 opened pull request #2357 (03master…fix-feedback-total-count): LB-1221: Feedback API endpoint returns confusing total_count https://github.com/metabrainz/listenbrainz-serv...

jivte: hi!

lucifer: U remember the api you told me to build for searching users

on the basis of search term

akshaaatt: changes done!

bitmap: are you dealing with MBS-11770 or MBS-12904 first?

MBS-11770: Recent items in dropdown shows less data than inline search https://tickets.metabrainz.org/browse/MBS-11770

MBS-12904: Beta: Relationships input lost when submitting edits https://tickets.metabrainz.org/browse/MBS-12904

(I can probably take the recent items one if you want to concentrate on the other)

jivte: yes

reosarevok: I was gonna look into the lost edit ones first, so feel free. (but I was also gonna ask if you wanted to look into MBS-12903 :))

MBS-12903: Beta: Guess feat. artist drops artist from title without adding it to artist field https://tickets.metabrainz.org/browse/MBS-12903

lucifer: So I implemented that api and need ur review

could u kindly review it whenever you get time

:)

will do

[musicbrainz-server] 14reosarevok merged pull request #2841 (03master…MBS-12901): MBS-12901: Show user website and bio on the admin user views https://github.com/metabrainz/musicbrainz-serve...

:D

mayhem: LB-1214, thoughts?

LB-1214: Add playlist covers https://tickets.metabrainz.org/browse/LB-1214

i think its a nice idea but we likely want to avoid users uploading arbitrary images.

maybe only allow them to choose from a set of auto generated templates from the cover art generator tool.

lucifer: about LB-1221 , I already implemented a fix in LB#2343 because I needed it for navigation

LB-1221: Feedback API endpoint returns confusing total_count https://tickets.metabrainz.org/browse/LB-1221

Combine pins and love/hate tabs: https://github.com/metabrainz/listenbrainz-serv...

monkey: ah cool, i'll close my PR then

[listenbrainz-server] 14amCap1712 closed pull request #2357 (03master…fix-feedback-total-count): LB-1221: Feedback API endpoint returns confusing total_count https://github.com/metabrainz/listenbrainz-serv...

"Kindly be informed that as per the YouTube Developer policies, it is not allowed to play subsequent tracks continuously" surprise

Oh well, it was worth a shot

Poop.

I think mayyyybe we can enqueue tracks in the currently active YT player, but that probably means a significant refactor of BrainzPlayer, and losing the ability to use both Spotify and Youtube to play music

What a PITA

the sooner we give up on YT, the sooner the pain stops.

I assume YouTube Music (which is kind of a separate thing) does not help in any way?

it doesn't have an API afaik

ok, I think we need to "think different" on the YT front.

we don't need their permission to play videos. we need their permission to find what we want to play, yes?

so, we find a way to crawl the data, collect it in MB and then use those links to play content. no API.

I like it, as long as it doesn't violate any of their Terms of Use.

probably does. and if it doesn't, then it will violate the terms of service they'll update in 2 weeks time.

Yeah, I suppose... :-)

we'll still be using the iframe API to play videos so same terms would still methinks. so yeah still violating.

but we dont need to be logged in to YT to do that, yes?

no don't think so

my take it, we may be violating terms of service, but will they ever know? to me it seems that they are getting their day because we want access to the api.

I think they have bigger fish to fry than us.

As long as you're not on their radar now...

hmm, yeah makes sense

and what if we are? they block us. then finally not more YT. fine.

i guess crawling youtube data for addition to MB is a fine thing in itself though.

I mean where we are is simple: provide a shit experience that doesn't reflect well on us or don't do it all.

Might be best to decide now to drop them now and save the coding effort?

that's where I am at now.

Given all that has transpired, I think that's a prudent decision.

I'll let monkey make that decision.

I mean, if they don't want the traffic heading to their site, forget them.

they don't care. we'd be .00000000000000000000000000000000000000000000000001% of their traffic

mayhem, monkey: btw soundcloud now offers a search api. however, the app creation form has been closed in forever. https://docs.google.com/forms/d/e/1FAIpQLSfNxc8...

True. I think I may have been just venting a bit.

i've had various friends at YT try and get a product manager to speak with me. nothing. no one cares. unless you bring a wheelbarrow of cash, they dont give a fuck.

that sentiment used to be reserved for the music industry, but its the tech industry now too

I think we may need to pivot on who/what we support.

keep supporting spotify until they cut that off (only a matter of time).

so, focus on funkwhale and navidrome. that is where our users are coming from now. lets focus on them.

Yeah, that article you shared the other day was very insightful on the situation.

lucifer: on the cover art for playlists -- yes we should support that. and once I finish the cover art maker, then we'll be ready for that!