#metabrainz

5moufl

new listens *just* arrived.

reload your page

great! it had been a couple of months, I should have guessed it'd take a few...

idk why it stopped working tho

its not the quantity of listens, but whatever spotify does.

spotify auth is also weird -- did you get an email from us about it?

we send an email when the connection is broken and we can't import more listens.

yvanzo: reosarevok: should we post the schema change announcement?

works for me

okay, I reviewed it again and it looks good to me, so I'll post

aabbi15: The “options” to “evaluate” are rather about the “promising frameworks” that can be used (fluent, i18next…). The translation folder should be in the repository where you are internationalizing the code, so `bookbrainz-site` at least since it seems to have the website UI, but I’m not into BB development. For example (using gettext), see the `po` folder in `picard` and `musibcbrainz-server` repos.

lucifer (IRC): Hi, im teribly sorry for disturbing again

I wanted to ask a question regarding a troi. So Im trying to generate a playlist in LB using mbids, and found this [troi patch](https://github.com/metabrainz/troi-recommendation-playground/blob/main/troi/patches/playlist_from_mbids.py). But it only accepts a filename to work with.

Should I change the code for this patch, Are there other troi patches that might work for me?

im terribly sorry for being a little inactive recently, trying to finish my midterms

rimskii[m]: no worries. you can take a look at https://github.com/metabrainz/troi-recommendati... for an element that accepts a list of recording mbids

thank you!

so what exactly it does once it passes the recordings to pipeline?

where I need to pass the elements then? create a playlist using LB API?

rimskii[m]: have you read our documentation? https://troi.readthedocs.io/en/latest/introduct...

most of these questions are answered there.

oh, im sorry

okay, thank you, ill check it

bitmap: Thank you!

thanks for your improvements!

lucifer (IRC): so, as I understood all I need to do is to get a list of recordings, pass them to PlaylistElement and submit to LB, right?

It sounds logical, but differs from the method used for exporting (they used patch in there), is this okay?

So I threw together a potential email output for the MJML project. Any thoughts?

I also ran it through HTML2text to see what it would output: https://pastebin.mozilla.org/Yibkga2x

I'm not entirely sure what's causing it to wrap the message in hr's, but the output isn't exactly terrible .

I also realized that I cut off the links in the pastebin - at the bottom, it has a numbered list of the links from earlier in the email

JadedBlueEyes: that looks quite nice for something you threw together :) the "─" characters seem to correspond to the mj-divider and hr tags in the original message, which makes sense, but perhaps you can configure html2text's line width to limit them?

Thanks :)

The --- lines don't seem to entirely match the hr's - there are two at the top, when there is only one hr in the template there, and there's no line between subscriptions and the sig, where there is in the template.

I think the html2text crate expects you to write your own formatter, so I expect it should be fixable there at least.

ah, you're right

if it allows for a customer formatter then that's great, otherwise I suppose we could have a post-processing step

custom*

Yeah.

More layers of processing xD

html2text | text2finaltext4real

xD

| finaltextfinaliser9001

Application flow wise for that project, I've drawn this:

r0d64-sfQdNHYHm6e9CsKP-q9ANLPgBp_LVSYiDnBLe-j_m-P899LjTGGpVdCyVogVlfZtyFCCg4rDOgwYVqBIe62w1RkS3i2UICIFA8gYYt7IOM4PmLEZg6_DXss1WcBeOZadWeYQYmzV_niZSylt9LaVOrRyIacJst3bz6rknimxdGRvWqxNi38bfADG4QwuuYsqyX4OM80e0PzOdfAX5kKLVOuZbezef6gZgWU6Yvhbh6Rv3NqOeXLqi7ESjjmKY3mN-tY9nrBajnsRctLLeOuF70_cZ7MFDYHr0RLMeNK5Ind9-N9Ey2LnfD0HbOatmE

Wow that's a long URL

But it made me think of a couple of things:

One is do we want any kind of queue for retrys? At the moment I don't think there's anything

For simplicity's sake I don't think it's worth setting up a whole queue system, but running a second try on a failed send could help with flaky delivery

Second is do we want any kind of batching mechanism? I think bulk subscription updates is a significant part of the workload, and reducing communication overhead could help there.

And third, on a slightly different note, is there any interest in enabling internationalization for the emails?

I don't think there's any support for that in the current systems, and I'm not sure how well mixing templates with links, formatting, etc and translation would go to be honest

But it could have a positive impact for non-english-speaking users

I don't think we need a queue, necessarily. unless the email address is dead, send failures aren't very common, and failing to send the mail doesn't actually lose the updates (as we keep track of the last edit # which was succesfully sent for each editor)

Yeah, exactly. And I know from experience that setting up systems like RabbitMQ is a pain

but we could perhaps detect certain failures and retry the send, as you said (I would have to check the logs again to see what kind of errors occur)

Actually, I think the SMTP server is responsible for retrying?

And when it fails there isn't any immediate feedback to the sender.

So ignore my bad there

for 2, having the mail server in your diagram accept a batch of submissions makes sense to me (Perl is not the ideal place for concurrency, and sending these one-by-one would probably slow down subscriptions significantly)

That sounds good to me, and was pretty much my thought.

yeah, just moving the email-sending to a separate process should be a measurable improvement

for 3, there is certainly interest in that, but I'm also not sure how it would fit into our current i18n setup tbh

it's beyond the scope of the initial idea, but we could discuss it with yvanzo

Yeah, it's definitely something to consider though

An extension goal maybe?

certainly :)