I had to disable multilingual plugin on discourse, it causes multiple issues, and caused a major failure after discourse upgrade. It doesn't seem to be well maintained.
2025-05-01 12131, 2025
Maxr1998 has quit
2025-05-01 12145, 2025
Maxr1998 joined the channel
2025-05-01 12129, 2025
julian45[m] joined the channel
2025-05-01 12129, 2025
julian45[m]
bitmap: sending you an invite to the authentik instance shortly; you should be prompted to set up a password and MFA (ideally in near future we can get back to a passwordless-first approach like kanidm), and then you should be able to log into google workspace after setup is complete (tested with a test user)
The existing code, scans the entire listens table in passes with increasing window sizes. In the current solution, the passes are limited to 3. so (1 + 3 + 9 = 13 months).
2025-05-01 12102, 2025
lucifer[m]
however, i am thinking about api use cases where the user can specify just the min or max ts.
2025-05-01 12151, 2025
lucifer[m]
if the search terminates after 13 months from the min ts with no results but there are results in the following yet unscanned range, it can be misleading.
2025-05-01 12108, 2025
mayhem[m]
Understood
2025-05-01 12124, 2025
lucifer[m]
it wouldn't happen in the existing code, because we do passes until the entire table is scanned.
2025-05-01 12138, 2025
mayhem[m]
Which is not ideal either...
2025-05-01 12109, 2025
lucifer[m]
so i am wondering if we should have two modes of search, one for our frontend which can query the api again when one api call couldn't find results.
2025-05-01 12127, 2025
lucifer[m]
but the default api to always search for the entire table.
2025-05-01 12105, 2025
lucifer[m]
this is for maintaining existing behavior. but this can always be very resource consuming and an easy way to get ddos-ed.
2025-05-01 12117, 2025
mayhem[m]
That
2025-05-01 12135, 2025
lucifer[m]
so maybe we should say that if you specify min or max ts then just 1 year ahead or before is searched.
2025-05-01 12154, 2025
lucifer[m]
and if you specify both, the both cannot be more than 1 year apart.
2025-05-01 12123, 2025
mayhem[m]
If we had a field in the DB that says: the previous listen to this one is x seconds ago.
2025-05-01 12143, 2025
mayhem[m]
If we had such a field, this would be a whole lot easier
2025-05-01 12107, 2025
mayhem[m]
But adding that field is basically making a linked list in the DB
2025-05-01 12113, 2025
lucifer[m]
yeah that could work but it would need to be updated on every insert and delete.
2025-05-01 12145, 2025
mayhem[m]
What if we had a script that inserts these values for when there are large gaps?
2025-05-01 12132, 2025
mayhem[m]
It just runs in the background. If you read a page and it ends with such a hint, you know where to seek to.
2025-05-01 12147, 2025
mayhem[m]
If you find no hint go to the previous page
2025-05-01 12101, 2025
lucifer[m]
hmm i see.
2025-05-01 12145, 2025
lucifer[m]
i'll think more about the implementation.
2025-05-01 12159, 2025
lucifer[m]
whether we want to keep in the listen table or a seperate one.
2025-05-01 12146, 2025
lucifer[m]
because we could also maintain a list of months or years for which a user has listens in the listen metadata table.
2025-05-01 12115, 2025
_BrainzGit
[musicbrainz-server] 14mwiencek merged pull request #3520 (03schema-change-2025-q2…mbs-13964): MBS-13964: Some recordings are missing a first release date https://github.com/metabrainz/musicbrainz-server/…
