#metabrainz

ok

sigh, this update_mb_dbdefs_for_hosts.sh script is always broken

or I don't understand how it works

mayhem do let me know if you are able to submit listens. Keep in mind that we do need to improve the submitted data from the app though.

I'm not.

the last two track changes have not been recorded.

LB seems to be down

That could be an issue?

🤦

Lol

one shall not play with these toys during downtime, yes.

sorry akshaaatt .

It’s fine 😂😂

yvanzo: update_mb_dbdefs_for_hosts.sh is completely broken for me, it just reports "No matching containers on aphex." for every machine

We should maintain a local fb though.

Thanks for testing mayhem. We got a new ticket because of it

Db*

bitmap: should I try it

yvanzo: yeah

lucifer: looking at the pop data now. what is the difference between those two queries?

yvanzo: I'm running it without any arguments because the args in the google doc didn't work

akshaaatt: I'll be doogfooding the LB app from now on. if it breaks, you'll hear from me, I promise. :)

Awesome! ⚡️⚡️

yvanzo: you have to edit the file to remove "sleep 30" first

phew i was worried wtf did i do wrong glad the server is down (i mean not really)

monkey: https://www.neptunesmac.app/

mayhem: first one is popularity by total listen count, second by unique listener count.

should we reach out and ask about LB support?

bitmap: it's skipped aphex and aretha as already up-to-date but it's now working for others, using arguments from the doc

I saw that one, thought the same thing

lucifer: understood!

yvanzo: OK, I guess it's just borked on macOS

lucifer: hard to evaluate like this, but it seems ok.

I merged the gsed PR already

so must be something else

would be good to put up on DSH

mayhem: there is artist, release, recording data available as well

But it's limited too, same as other ones I've seen:

>automatically detect currently playing music from Apple Music or Spotify

bitmap: it stopped on patton, now restarting

packed with radiohead, and RHCP, the data is likely ok, lucifer

i didn't put it on dsh because not sure what params to accept.

what params?

mayhem: to record any app in the listening apps list, just play one or two songs.

monkey: better than nada.

bitmap: did you update your local working copy of server conf?

force shutting isn’t necessary

top recordings is a mbid with two listen counts.

yvanzo: yeah

I'm on 6132bf00b231308de41be93da2364c7e5dd9e690

jasje: I think the problem is with LB being down. but likely it works now. I'll check once LB is up.

doesn’t matter if LB is up or no

bitmap: Sometimes it's also stopping with "Host key verification failed. fatal: Could not read from remote repository."

listening apps will show regardless

all of this is available.

bitmap: done

thanks

jasje: yes, I can see the LB app knowing the current playing now track.

jasje those are showing for him.

bitmap: was json-dump not included at purpose?

The issue is only with the submissions currently

oh then its okay. looks like i read an older convo

lucifer: why dont we have make one DSH query and then have an extra param that tells which table to use. then list the available tables in the desc for the query.

services should be coming back now

(and please add the available tables for recording and artists similarity while you're at it)

oh, LB must be back. listen arrived. :)

yvanzo: that looks like an oversight

okay, updating it now

apparently if you run the script without any arguments it should update all containers on all hosts?

jasje: akshaaatt: all sorted, thank you!

bitmap: yes

done

yay!

yvanzo: ty

I'll restore standby service on pink now

yvanzo: can you pull docker-server-configs on pink? now that's not working lol

ok

I tried ssh agent forwarding

yvanzo: I got it working with GIT_SSH_COMMAND='ssh -i ~/.ssh/docker_server_configs_key' git pull origin master

👍

I'll try to fix the config still

mayhem: i am not sure that will work.

how do you want to query this table for instance

ah, yes. and each table is going to need different params.

if you can load these datasets on wolf, I can add the DSH and test.

yvanzo: I guess we have a separate deploy key on pink but not on floyd

sure i'll copy those to wolf.

I checked deploy keys in the repo settings

thx

bitmap: it seems that all websites are back already, making the announcement

yvanzo: yup

ty

Smooth! Nicely done team

monkey: neptunes creators have been asked to add LB support, monkey

only took an extra 5 mins this time, not terrible

Thx !

👏

mayhem: monkey: lucifer: you can restart any cron jobs that were stopped

monkey: BB is back

Yep, I checked as well, thanks :)

pink standby service is back, barman is running smoothly

(I tweeted about it for MeB and MB only)

I restarted cron in json dump, search indexes dump, and production cron containers

done

(cron jobs)

thanks all

working on improving the pg cluster so that switchovers require less (possibly zero) downtime, still in the testing phase though

!m bitmap

You're doing good work, bitmap!

monkey: rescrobbler scrobbles everything, even if it is playing on mobile.

but only, of course, if the desktop machine is not sleeping.

bitmap: Found the problem with pink: the key was named docker_server_configs_key instead of the default id_rsa.

which leads to .. dups. sigh.

Yep, that's what I was trying to point out

I was trying to ask you exactly this question. lol

If you have spotify open on desktop with rescrobbler and also on mobile with LB app, you'll get two listens.

indeed.

There's no real way to figure out which one is 'correct"

and the listens are not off by some seconds, but by minutes.

That's the issue indeed where deduplication is concerned

akshaaatt: https://listenbrainz.org/user/rob/

bitmap: all other repositories have IdendityFile specified in ~/.ssh/config but docker-server-configs

That is one of the reasons why I wouldn't suggest deprecating the spotify importer

I see that the desktop scrobbler and LB app have quite different timestamps as to when the track started playing.

zas: is ~root/.ssh/config managed using ansible?

monkey: understood, but I think there is a discrepancy somewhere and when resolved, might fix this issue.

mayhem: we record the initial play button hit timestamp

yvanzo: nope

huh. it seems that rescrobbler does this too.

ok, I'll dig into this tomorrow, but outta time for today.

Right

Fix how mayhem? Because each scrobbling app might have a different mechanism to decide what the timestamp is

zas: is it fine to keep using id_rsa identity file for cloning docker-server-config repo on hosts?

yvanzo: I think that may have been me

monkey: right now the duplicates seem to be off by the duration of the track. something is not right.

if both were working right, the differences in timestamps should be small.

at some point I wanted to separate the keys used for sshing between servers and the deploy keys for our private repos

seconds, not minutes.

My point is that "working right" is vague :) Looks like rescrobbler chooses the end of the track as the listened_at timestamp maybe?

yvanzo: well, it would be better to use deploy keys I guess

bitmap: which is great, and we should probably do for docker-server-configs repo too.

btw, deploy keys exist (see https://github.com/metabrainz/docker-server-con...)

zas: it's a deploy key, just the default one

mayhem: judging by the track_duration /2 and timestamp diff