personally, I think that a deleted listens table is one more moving part in the system and that if we can get away without doing it, that would be better (until someone complains I guess)
2023-01-16 01640, 2023
lucifer
alastairp: we already have that table.
2023-01-16 01652, 2023
alastairp
oh, well then. that changes things
2023-01-16 01655, 2023
alastairp
:)
2023-01-16 01608, 2023
zas
Yes, we do. One limitation is arising: we cannot use 10.2.2.x network, so it comes as an additional network, but all nodes will be connected through it.
right, I thought you were asking "should we start storing deleted listens so that we can improve stats?" rather than "should we periodically copy our existing deleted listens to spark so that we can improve stats?"
2023-01-16 01643, 2023
mayhem
sorry
2023-01-16 01652, 2023
alastairp
lucifer: yeah, just finishing up deleted listens first :)
2023-01-16 01607, 2023
lucifer
alastairp: ah yes makes sense
2023-01-16 01655, 2023
alastairp
lucifer: why is track_name gone?
2023-01-16 01603, 2023
mayhem
it exists in data.
2023-01-16 01605, 2023
lucifer
it'll be part of jsonb data
2023-01-16 01606, 2023
BrainzGit
[listenbrainz-android] 14dependabot[bot] opened pull request #26 (03main…dependabot/gradle/androidx.compose.material3-material3-1.1.0-alpha04): Bump material3 from 1.1.0-alpha03 to 1.1.0-alpha04 https://github.com/metabrainz/listenbrainz-androi…
[listenbrainz-android] 14dependabot[bot] opened pull request #27 (03main…dependabot/gradle/androidx.compose.material3-material3-window-size-class-1.1.0-alpha04): Bump material3-window-size-class from 1.1.0-alpha03 to 1.1.0-alpha04 https://github.com/metabrainz/listenbrainz-androi…
2023-01-16 01613, 2023
BrainzGit
[listenbrainz-android] 14dependabot[bot] opened pull request #28 (03main…dependabot/gradle/com.google.android.material-material-1.8.0-rc01): Bump material from 1.8.0-beta01 to 1.8.0-rc01 https://github.com/metabrainz/listenbrainz-androi…
2023-01-16 01622, 2023
mayhem
this looks ok to me lucifer .
2023-01-16 01647, 2023
alastairp
and recording_msid is the reverse - pull it out of `data` because we use it often?
2023-01-16 01655, 2023
lucifer
i intend to use recording msid instead of track name for unique index henceforth.
yes, the schema looks fine to me too. my intuition is that the listened_at and tz_offset is correct for the types of computations that we need to do, but it'd be good to try and actually get the required data from a test db before we go ahead with the full migration
2023-01-16 01608, 2023
lucifer
makes sense
2023-01-16 01636, 2023
alastairp
when you do `at time zone 'x'` in an sql query, do you know in what formats x can be?
2023-01-16 01600, 2023
alastairp
does it need to be 'Region/City'?
2023-01-16 01619, 2023
alastairp
or would we just do `SELECT listened_at + tz_offset as local_time` ?
2023-01-16 01643, 2023
lucifer
the latter
2023-01-16 01609, 2023
alastairp
we need to check what timezone pysopg2 will put into the resulting datetime object in this case
2023-01-16 01653, 2023
lucifer
should be utc i think but need to check.
2023-01-16 01613, 2023
alastairp
specifically, we should check if it's utc or server time
2023-01-16 01602, 2023
alastairp
because `SELECT listened_at + tz_offset at time zone 'UTC' as local_time` is wrong too
2023-01-16 01611, 2023
alastairp
anwyay, we can try it out and see what the results are
2023-01-16 01659, 2023
lucifer
yeah makes sense.
2023-01-16 01632, 2023
alastairp
I have a feeling that it might be better to extract listened_at always as UTC, and update the listen object with a datetime at the correct timezone (using `.astimezone()`) in python - just to avoid getting an object out of the database with an attached tz, but then it actually being the date at a different tz
2023-01-16 01641, 2023
alastairp
but as I said, we can test
2023-01-16 01614, 2023
lucifer
i don't think we can get a correct timezone without storing timezone instead of offset.
2023-01-16 01635, 2023
alastairp
yes, I suspect you're right
2023-01-16 01657, 2023
lucifer
or i guess we could make a table to map INTERVAL 5h 30 mins to UTC +530 time zone and use that
2023-01-16 01612, 2023
alastairp
but I think that's fine, I have no problem with trying it out and seeing what the code looks like
2023-01-16 01643, 2023
atj
what about DST changing offsets?
2023-01-16 01618, 2023
lucifer
the client would submit an offset so we are hoping that the client is applying DST on its end.
2023-01-16 01631, 2023
atj
ah ok
2023-01-16 01635, 2023
jivte_ has quit
2023-01-16 01607, 2023
alastairp
atj: this is why we settled on storing +0100 instead of 'BST' or 'Europe/London'
2023-01-16 01650, 2023
atj
yeah, i see the logic, as the api client will know the offset at the time of the listen
2023-01-16 01656, 2023
alastairp
yep
2023-01-16 01625, 2023
alastairp
(also, I tried to work out how to automatically calculate 'Europe/Madrid' from python without user input... not easy
2023-01-16 01600, 2023
monkey
Nothing is ever easy when it comes to time, is it?
2023-01-16 01621, 2023
alastairp
monkey: let me take some time and get back to you on that...
2023-01-16 01628, 2023
monkey
And I guess we should be thankful that we don't have to handle relativistic time (yet)
2023-01-16 01657, 2023
alastairp
well, we allow people to import listens from the past
2023-01-16 01654, 2023
lucifer
what about listens from the future
2023-01-16 01613, 2023
atj
"how to automatically calculate 'Europe/Madrid' from python" you mean going from offset -> zone name?
2023-01-16 01624, 2023
antlarr has quit
2023-01-16 01621, 2023
alastairp
atj: yes
2023-01-16 01630, 2023
jivte_ joined the channel
2023-01-16 01645, 2023
antlarr joined the channel
2023-01-16 01602, 2023
atj
not sure that's possible, given each offset may match multiple timezones?
2023-01-16 01656, 2023
alastairp
atj: right, and another motivation to only use UTC hour offsets instead of named time zones
2023-01-16 01601, 2023
Sophist_UK has quit
2023-01-16 01636, 2023
antlarr has quit
2023-01-16 01653, 2023
antlarr joined the channel
2023-01-16 01622, 2023
antlarr has quit
2023-01-16 01632, 2023
antlarr joined the channel
2023-01-16 01637, 2023
vibhoo_24 joined the channel
2023-01-16 01600, 2023
bitmap
reosarevok: yeah, that doc is out of date, we no longer pass $c as a prop (you have to use react context or getCatalystContext if not inside a component)
2023-01-16 01618, 2023
reosarevok
Thought so. I'll update it
2023-01-16 01620, 2023
antlarr has quit
2023-01-16 01643, 2023
antlarr joined the channel
2023-01-16 01625, 2023
bitmap
re MBS-8668 do you have an example of which error no longer triggers?
note: we are deploying vswitch changes to all nodes right now, a new IP in 10.10.10.x network will be added
2023-01-16 01623, 2023
antlarr has quit
2023-01-16 01639, 2023
antlarr joined the channel
2023-01-16 01646, 2023
agatzk has quit
2023-01-16 01621, 2023
antlarr has quit
2023-01-16 01639, 2023
TOPIC: MetaBrainz Community and Development channel | MusicBrainz non-development: #musicbrainz | BookBrainz: #bookbrainz | Channel is logged; see https://musicbrainz.org/doc/IRC for details | Agenda: Reviews
2023-01-16 01641, 2023
antlarr joined the channel
2023-01-16 01652, 2023
atj
vswitch changes applied and nothing appears to be on fire
2023-01-16 01607, 2023
zas
(yet) ;)
2023-01-16 01609, 2023
alastairp
I can change that if you want?
2023-01-16 01613, 2023
jasje_ joined the channel
2023-01-16 01620, 2023
antlarr has quit
2023-01-16 01651, 2023
antlarr joined the channel
2023-01-16 01653, 2023
jasje_
akshaaatt: in EntityTestUtils, what is the loadResourceAsString function?
akshaaatt: I'll be afk for a while, won't be active for a week or so. I'll try to wrap up work on tickets for aerozol.
2023-01-16 01622, 2023
antlarr has quit
2023-01-16 01642, 2023
agatzk joined the channel
2023-01-16 01627, 2023
antlarr joined the channel
2023-01-16 01618, 2023
serial-ata joined the channel
2023-01-16 01636, 2023
BrainzGit
[listenbrainz-server] 14alastair opened pull request #2338 (03master…canonical-release-connection): Generate canonical release redirect only in the mb schema https://github.com/metabrainz/listenbrainz-server…
2023-01-16 01656, 2023
alastairp
lucifer: ^ I think this is the only change we need for the mapper bug from the other month
2023-01-16 01634, 2023
BrainzGit
[listenbrainz-server] 14alastair closed pull request #2288 (03master…canonical-data-mb-conn): Remove lb_conn option from canonical musicbrainz data dump https://github.com/metabrainz/listenbrainz-server…
People up: atj, bitmap, lucifer, monkey, reosarevok, alastairp, yvanzo, mayhem, zas, akshaaatt, CatQuest, Pratha-Fish, yellowhatpro, riksucks, Freso – anyone else who wish to give review, let me know ASAP. :)
2023-01-16 01610, 2023
Freso
atj: Go!
2023-01-16 01611, 2023
Sophist-UK joined the channel
2023-01-16 01627, 2023
atj
hi
2023-01-16 01644, 2023
CatQuest
fish
2023-01-16 01606, 2023
Pratha-Fish
🐟
2023-01-16 01617, 2023
aerozol
Mōrena! I’m here too Freso :)
2023-01-16 01620, 2023
CatQuest
:D
2023-01-16 01624, 2023
vibhoo_24
Freso: count me in
2023-01-16 01635, 2023
Pratha-Fish
^_^
2023-01-16 01645, 2023
atj
last week I worked with zas to test deploying a Hetzner vSwitch to all servers so they can communicate securely
2023-01-16 01636, 2023
atj
as part of that work i simplified the netplan and shorewall configuration in ansible so it should be a bit easier to understand
2023-01-16 01612, 2023
atj
we just added the vSwitch VLAN to all servers today and no issues have been reported (so far)
2023-01-16 01633, 2023
atj
aerozol: go
2023-01-16 01636, 2023
monkey
vWell done
2023-01-16 01602, 2023
aerozol
Kia ora! I had a lovely break and finally finished Hades (the game)
2023-01-16 01640, 2023
mayhem
atj: thanks for working on that, thats going to be hugely helpful for us.
2023-01-16 01658, 2023
aerozol
Apart from that I finally tidied some wiki pages (esp the userscripts one), kept on top of discussions, and have been doing lots of looking at other YIM-type stuff to inform the next one. Hoping to get onto the design early early
