#metabrainz

yeah, I love love that. big and always easy to get in there.

i get the feeling you like that place ruaok :P

yeah.

Roger roger.

off by a second.

:D

I pushed on listen-page-player with some playback imporvements (only JS, so no merge issues, i swear !)

zas: we're motivating at 14:15

k

I cherry picked the spotify STFU branch and will commit this branch

why'd you remove the currently-playing permission?

if I did it, then it was a merge conflict, sorry.

please add it back in, that would cover the error.

also, please add a check/test for this.

oh, no worries. I think that might be the reason for the error.

yes, sure.

iliekcomputers: I guess blocked user shouldn't be allowed to comment. Right? 🤔

on reviews?

blocked users can't make reviews right?

iliekcomputers: Yeah!

then, yea.

shouldn't be able to comment either.

I thought so too! But then I thought .. like.. poor blocked users! 🤣

wooo, I haz listens!

I still have a couple of other things to resolve in my setup, but they seem pretty simple.

we will need to rejigger some bits of spotify UI -- the spotify integration now takes on a new and more complex meaning.

e.g. right now we link and force users to record listens in order to play on the listen page.

that isn't cool -- the user should be able to choose either or, or both.

but that is for the afternoon. i can do stuff like that, no problem.

want me to work on anything in the meanwhile?

if you have nothing to do, think about what I just said above.

we need to move the "link spotify" feature out of the realm of "import" and more into "something to use with LB".

makes sense?

yeah.

we should take permissions accordingly as well.

if the user doesn't want import, we shouldn't ask for permission to see their recently played

iliekcomputers: One thing is bugging me for quite some time! Suppose a user deletes his/her review. What happens to the comments on that review? Should they also be deleted?

ruaok, zas I'm at the market

iliekcomputers: exactly that.

build on `listen-page-player` fixed.

ohh, thanks.

yeah, I would've needed help on that anyway.

soooo, when we link the user's spotify account, do we give them a list of features they can opt in too?

why is it active_section now?

Mr_Monkey: ^^

ruaok: I think that makes it easier to understand

ah, I see. I certainly didn't get it at first. :)

thanks for fixing.

wrt to `soooo, when we link the user's spotify account, do we give them a list of features they can opt in too?`

Mr_Monkey said that we need to have all those perms to just play full length tracks from spotify

so, there are two classes of perms then: listen & record.

so we should enable people to chose either or both sets.

sounds good to me.

that said, we're complicating the spotify setup that we were hoping to release.

I wonder if it makes sense to hold off on that -- I don't like the idea of pushing a release and then changing things right away.

AAAAAND... people may need to tweak their perms for the next release and re-connect.

thoughts, iliekcomputers?

asking people to reauth two times isn't really ideal imo

we can hold off on the release. (although we'll probably need a long test cycle for this feature too)

why do we need birthdate and email?

iliekcomputers: Somehow, Spotify needs it to verify if the user is a free or premium account

…

:|

I don't think it needs to be soo long. The listen recording is the thing that was tricky to get right. I think we're good on that.

a week might suffice.

ruaok: yea, the play feature isn't data critical, so it _should_ be okay even if we find bugs there. (but we'll try to not have bugs :D)

sounds good to me.

so, for the perms nonsense, we should add a note: "In order to play full length tracks, spotify requires a permission to ask for your birthday. We're not going to look at the data -- see the code here: ,<link to code>. Sorry, but this is not our choice. Proceed or Cancel"

iliekcomputers: great.

but lets see if we can put these features to bed today.

Let me double check the perms.

:D

*forehead

my follow server is refusing connections because it cannot connect.

e3d95f7352f3 rabbitmq:3.6.5 "docker-entrypoint.s…" 15 hours ago Up 7 minutes 4369/tcp, 5671-5672/tcp, 25672/tcp listenbrainz_rabbitmq_1

any ideas, iliekcomputers?

any changes in your docker-compose.yml?

my repo has no local changes compared to our branch

okay, weird.

can you `docker exec -it listenbrainz_web_1 bash` and then try `python manage.py run_follow_server` there?

yes, that works.

and going into the follow_server can also connect to rabbitmq. very odd.

dockerize?

the server doesn't connect, loops, the connects and starts as expected.

but upon connecting something goes wrong, I think.

Adding a few debugs here might help

WEBSOCKETS_SERVER_URL = 'http://localhost:8081'

isn't actually correct, no? because the web_1 container tries localhost and it doesn't work.

WEBSOCKETS_SERVER_URL = 'http://follow_server:8081' ?

Right, but I guess that won't work from the browser

Two config values?

why is it working for you and Mr_Monkey? is it?

> web_1 | 2019-01-24 15:21:55,438 INFO 172.18.0.1 - - [24/Jan/2019 15:21:55] "GET /socket.io/?EIO=3&transport=polling&t=1548343315286-144 HTTP/1.1" 404 -

these lines in the web_1 container are bugging me.

are we using polling? they go 404 for web_1, but when I use it on the command line, it works.

I get those errors too

There is a bug somewhere in this branch

Lemme loom

Look

lol

can you review the merge I did after midnight?

I suspect that is where the bug is.

Sure, on it.

we found a problem wrt to connecting to websockets on the client side.

noice, what was it?

We changed what properties are passed to the template, and web_sockets_server_url isn't one of them anymore

ohhh

trying fix now

fix looks good. pushed.

the data being sent by the js is incorrect.

let me fix.

but otherwise works for me too.

"Enhance any landscape with our world class signature firepits!"

Sometimes we get interesting spam

pushed latest commit fixing the event listeners on the js client.

I see listens arriving the client now, great.

but there are too many arriving

one playing_now and one listen, i guess?

let me add more logs

are those retransmits because of an incorrect ack, maybe?

pushed again.

oooh it sent the now-playing notification

twice

i guess i forgot to add dedup for playing now...

on it.

ah, fixed a typo in my javascript, https://magicisrc-beta.kepstin.ca/ is working now as a proof of concept against test.musicbrainz.org

hopefully I can get the isrc submission stuff working again over the weekend :)

iliekcomputers: ping me when you have a sec. we have a UI issue to discuss.

i'm here.