#metabrainz

/

      • wargreen joined the channel
      • wargreen has quit
      • Rotab joined the channel
      • wargreen joined the channel
      • wargreen has quit
      • wargreen joined the channel
      • aerozol
        lucifer: My listens cover art has gone weird. Sometimes the correct compilation cover, sometimes no cover, and sometimes the cover from another album the recording is from (but a rollover always displays the correct compilation title :S )
      • wargreen has quit
      • wargreen joined the channel
      • lucifer
        aerozol: i see. can you post some examples like which listen is linking to the wrong cover and what the right one would have been?
      • jivte: 👍 sounds good
      • Killingme2 joined the channel
      • Killingme2 has quit
      • jivte_ joined the channel
      • MRiddickW has quit
      • aerozol
        lucifer: everything on the first page of listens should have a black cover with some white details on it, those are correct
      • monkey
        Sounds like a various artists compilation issue again
      • d4rk has quit
      • d4rkie joined the channel
      • lucifer
        aerozol: to confirm this is the right one, https://musicbrainz.org/release/a9df3598-e040-4... ?
      • aerozol
        Yup, and this one for the ones at the bottom: https://musicbrainz.org/release/990dcf9d-518a-4...
      • lucifer
        i see.
      • the throwback track is instead matching https://musicbrainz.org/release/e9b6aae3-3fad-4...
      • which kinda makes sense because we prefer album over album + compilation...
      • the fix for this would be to detect album streams in listens.
      • aerozol
        I thought I'm submitting the album with my listens? I always get the specific album cover
      • lucifer
        hmm right...
      • jivte_ has quit
      • aerozol
        I'm using foobar2000 ' ListenBrainz 2' submitter, not sure what it sends soz
      • Checked, it would be sending the album MBID
      • *should
      • This is the rollover, which displays the name of the ‘correct’ compilation, on top of the wrong album image https://usercontent.irccloud-cdn.com/file/KnCIg...
      • jivte_ joined the channel
      • lucifer
      • jivte_ has quit
      • jivte_ joined the channel
      • aerozol
        Looks right!
      • jivte_ has quit
      • BrainzGit
        [listenbrainz-server] 14amCap1712 opened pull request #2270 (03master…fix-caa-fe): Add missing return in getAlbumArtFromListenMetadata https://github.com/metabrainz/listenbrainz-serv...
      • [troi-recommendation-playground] release 03v-2022-11-29 has been published by 14amCap1712: https://github.com/metabrainz/troi-recommendati...
      • [listenbrainz-server] 14amCap1712 opened pull request #2271 (03master…update-troi): Update troi to v-2022-11-29 https://github.com/metabrainz/listenbrainz-serv...
      • lucifer
        mayhem: almost December, we should probably finalize and start work on the Year in Music.
      • mayhem
        yep. I guess I should start a YIM 2022 document.
      • chirayu999 joined the channel
      • chirayu999 has quit
      • loujine has quit
      • loujine joined the channel
      • lucifer
        mayhem, alastairp: about local timestamps in listens, we decided to add a new column for storing the offset of the user's timezone at that time for each listen. (https://chatlogs.metabrainz.org/libera/metabrai...)
      • however, there are 2 issues.
      • 1) we have timezones like UTC+7, UTC+8 in LB time zone options. these don't automatically change with DST. when DST changes, the user would have to automatically update their time zone in LB for the changes to take place.
      • mayhem
        oh. how did we miss this?
      • (rhetorical question)
      • lucifer
        However, we also have timezones like Europe/London etc which automatically update with DSTs.
      • so a simple solution would be to ban timezone of the first type or add strong warnings against using those.
      • alastairp
        yeah, that seems like a mistake to have the user preference store an offset
      • do you know if there was a reason for it?
      • lucifer
        we currently don't store an offset but the timezone name directly?
      • the offset thing is yet to be added.
      • alastairp
        ah, sorry. let me look at my preferences
      • sorry, I misunderstood what you were saying
      • I would clean up this list to only include the 'Region/City' variations, and only allow these values to be set
      • lucifer
        yes makes sense
      • there's another issue related to using these variations. let me create an example to explain it.
      • alastairp
        sure thing
      • Maxr1998_ joined the channel
      • Maxr1998 has quit
      • lucifer
      • compare the last line in the two pastes.
      • alastairp
        right. was/is there a DST change then?
      • lucifer
        the second paste is from our prod server which is using an outdated pg version. the former is from the latest pg image.
      • fiji decided not to have a DST change this year.
      • alastairp
        right. postgres has a built-in tzdb?
      • lucifer
        right but it needs to be updated manually
      • i don;t think we ever do that in prod.
      • alastairp
        > we decided to add a new column for storing the offset of the user's timezone at that time for each listen.
      • what do you plan to store here. the tz name, or the offset?
      • lucifer
        that was going to by next question. i think we wanted to go with offset value.
      • alastairp
        because if we compute and store the hour offset based on timezone name in python at submission time, then we can update the python tzdb package when necessary
      • lucifer
        i see makes sense
      • alastairp
        although if we do that then we won't be able to show the timezone name (e.g. EST/EDT) with the timestamp when we show it in LB
      • lucifer
        i am still wondering if we should allow users to submit a local timestamp directly as well
      • yeah :/
      • alastairp
        wondering in which way? allow it, or deny it?
      • lucifer
        allow it
      • alastairp
        I still think that's a good idea (I believe we've discussed it before?)
      • lucifer
        initially yes but not in the latest discussion.
      • alastairp
        note that both RFC3339 and ISO8601 don't allow a timezone name as a specifier, only an hour offset: https://ijmacd.github.io/rfc3339-iso8601/ (at least from my reading of this)
      • ah, I see
      • it's possible that with a timestamp in UTC (or time+offset) + a user preference with a timezone, we'd be able to compute the name of the timezone based on knowing when it was
      • lucifer
        right if the user is directly submitting a timestamp then the offset would suffice, assuming their player/device is upto date with timezone changes.
      • alastairp
        however this wouldn't work if the user was in a different timezone than their current preference when they submitted it (I'm not sure this is a huge problem though... sounds like it might be inventing more problems for something that doesn't happen often)
      • lucifer
        yeah true. someone will eventually complain about that but not a deal breaker for most.
      • alastairp
        if they submit the offset then that still doesn't allow us to name the tz in terms of PDT/PST/ECT/ etc
      • lucifer
        right
      • yvanzo
        O’Moin
      • lucifer
        i guess there could be another field for timezone but uh.
      • alastairp
        yeah right, I'm not entirely convinced that this type of representation is necessary
      • I may have just invented it
      • fwiw, last.fm doesn't seem to show a timezone, just "local time at scrobble"
      • lucifer
        i see
      • BrainzGit
        [listenbrainz-server] 14amCap1712 merged pull request #2270 (03master…fix-caa-fe): Add missing return in getAlbumArtFromListenMetadata https://github.com/metabrainz/listenbrainz-serv...
      • alastairp
        hi yvanzo!
      • yvanzo: a question about SEC updates, the comment on a ticket says that if you either dismiss the alert in github or create a ticket in the affected project and link to the SEC ticket that this will cause the ticket to close
      • but if I directly fix the issue without first making a ticket, will github close the SEC ticket? (I already see that in the dependabot security list on github the ticket has recently been closed due to my push)
      • yvanzo
        reosarevok: about yesterday’s support request, I’ve just entered their email as verified directly in the database, but have you already dealt with verification email not arriving (apparently not even in spam folder) before? Any clue of possible causes?
      • alastairp
        never mind, it just took github a while to close the ticket on jira. everything looks fine now
      • reosarevok
        yvanzo: I have seen it a couple times, their mail provider might just eat it fully, not sure about the causes tho
      • yvanzo
        alastairp: good to know, I thought it wouldn’t
      • alastairp: it sometimes happens the webhooks in charge of updating the ticket fails instead
      • lucifer
        alastairp: i guess we could store both local timestamp and time zone? and both being optional.
      • alastairp
        lucifer: in postgres? I guess there's no such thing as a "local timestamp", so it'd need to be timestamp, offset, and timezone (the timezone used to compute the offset, either the user preference, or a value passed by the client) as 3 different values
      • lucifer
        right that's what i meant. the existing listened_at, local_listened_at, time zone.
      • alastairp
        right. and what data type did you want local_listened_at to be?
      • lucifer
        timestamp with time zone. i know PG would discard the timezone there.
      • yvanzo
        reosarevok: thanks, replied about it.
      • alastairp
        my current intuition is that an offset is much more useful than a timezone. I guess in terms of being able to convert and show a local time
      • AT TIME ZONE with a timezone name would work in SQL too, but it suffers from the problem of an out-of-date time db like you mentioned
      • lucifer
        pg and python would easily apply the offset to the timestamp value so i think its equivalent
      • right i guess we'd have to do it in python. which we update frequently enough
      • alastairp
        just to confirm about the out of date timezone db, can we pull a new minor version of the postgres image that we use and have an updated tzdb?
      • lucifer
        yes should work i think
      • alastairp
        because as long as we stay on a recent enough major version of pg that allows us to do this regularly then maybe that will work
      • lucifer
        yup makes sense
      • going back to square 1, i think what we want is a way to specify a global time zone for all listens and optionally a way to override it one the listen level.
      • optionally because as discussed last time not sure if this some thing many users would want.
      • alastairp
        I'm thinking of one of the blog posts about time/calendar which says something like "use concepts for future tasks [i.e. an event in London on the 2nd of Feb next year] but turn it into something concrete when it happens"
      • so for me I'm not sure if a timezone name is "concrete" enough, or an hour offset is better
      • yes, agreed that it should be optional at the listen level
      • I think that we should also bring in aerozol and monkey to discuss if they have any ideas about how we should display historical dates to users
      • lucifer
        i think timezones are concrete enough because they'd account for DST and are convertible to offsets at will.
      • alastairp
        if we want to just show "the local time at the time the listen was submitted" then an offset might be OK
      • I have a niggling feeling that there are some timezones which aren't historical
      • lucifer
        for showing dates to users, we wouldn't need time zones though, the browser would format it accordingly.
      • yeah i am aware of that but that applies to pre-1970 dates afaik and we only allow >2002 so not a dealbreaker i guess
      • alastairp
        there are problems with some timezones being turned into aliases in the db, but this appears to be a problem only for dates before 1970
      • yeah, right
      • good point about the browser!
      • lucifer
        the main use case for this would be say global daily activity stats.
      • *current main use case.
      • alastairp
        I guess here the CET is actually shown by the browser because I'm currently in CET
      • lucifer
        yes
      • alastairp
        so if I listened to something at 3pm in July, should I expect it to show "2PM CET" or "3pm CEST"
      • lucifer
        i see.