In T278444#7055808, @Samwilson wrote:

This is pretty much done, and is working at https://ocr.wmcloud.org/api.php

@Inductiveload Thank you for the patch. Can resolve this task now?

This is currently timing out with Tesseract 4. Might be worth checking it out after the upgrade http://ocr-test.wmcloud.org/api.php?engine=tesseract&image=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F4%2F43%2FPhilolaus_-_LROC_-_WAC.JPG&lang=&oem=1&psm=5

I'm not sure how to follow up on this, can we get more data on this error?

In T275546#6982109, @MusikAnimal wrote:

We'll probably want to adjust how we handle exceptions, similar to what we did for WS Export (capturing common ones). I can make a follow-up PR to capture this error as well as setup the emails.

In T276672#6916587, @Xover wrote:

Random, possibly not useful or relevant, thought: there's an effort somewhere to tighten the privacy policy in such a way that IP addresses are no longer visible (not even to Checkusers). IPs are also not very useful as an entry in a "Contributors to this book" list. Perhaps both issues could be addressed by grouping all logged-out contributions at the end as "…, and n anonymous contributors."?

@Samwilson Do you know if this is a one-off problem on a single page or if this is more widespread?

In T277328#6915753, @JJMC89 wrote:

I would be cautious with restarting. If I'm not mistaken, the bot loses any queued pages when it restarts.

If I understand what's being said here correctly, restarting the bot is the only way to get it back up right now.

In T273987#6881479, @Samwilson wrote:

The basics of switching to the new replicas design is ready for review. In discussion, we decided to disable the pagination of revisions within an event (i.e. the list accessed via the 'View all edits' link on an event's page), because doing this requires switching to a timestamp-based pagination, rather than a numerical-offset one. This can be fixed in a follow-up task: T276413: Event Metrics: Re-enable pagination of event revisions

I can confirm this happens when you have the "Use non-JavaScript interface" preference checked

In T275735#6863306, @Samwilson wrote:

The default cache time is now 6 hours, and I've updated the pruning cronjob to also run at 6 hour intervals.

I don't think there's anything much to QA here.

@dom_walden I'm unable to reproduce this anymore. I've downgraded Calibre to 4.13.0 anyway 'cause that's what we have in production but those examples in the description are downloading fine now.

PR: https://github.com/wikimedia/ws-export/pull/336

@Samwilson Keep in mind that this is an "investigation" and no actual "code" is required.
Writing down what we discussed yesterday plus whatever you find regarding what error messages are worth handling (or not) is good enough. We'll create some tasks out of this and size them in our next estimation.

In T274561#6829490, @Samwilson wrote:

I suggest we add MediaWiki:WS_Export.json and use it to store the font name, and then the tool can retrieve that page and use the correct font. Then, each Wikisource can set their own font (or ask us to set it for them).

This is somewhat at odds with the existing MediaWiki:Wsexport i18n.ini pages, but in T264699 we're going to remove those.

Does this sound okay?

@Krinkle thank you for flagging and taking care of this.

In T270372#6802384, @Denis_Gagne52 wrote:

Same behaviour was observed in fr:Wikisource with links pointing to the same page (first char=#)
example : [ https://wsexport.wmflabs.org/?lang=fr&page=Les_p%C3%A8res_du_syst%C3%A8me_tao%C3%AFste/Tao-Tei-King&format=epub-3&fonts=]
The links in the summary will take you back to Ws website.

In T272119#6779856, @Samwilson wrote:

Patch is merged and released to prod in 2.2.2.

We're still getting quite a few of these timeouts, but from what I've looked at it seems that they might be related to really large books, such as https://he.wikisource.org/w/index.php?title=%D7%A2%D7%A5_%D7%97%D7%99%D7%99%D7%9D&action=info (506 subpages).

I wonder if we should look at doing T222690 as a sort-of fix.

I've managed to get the same visual results with and without --enable-heuristics by setting the following options --disable-delete-blank-paragraphs --disable-format-scene-breaks --disable-markup-chapter-headings --disable-unwrap-lines but I didn't get any gains in terms of performance. I tried multiple combinations and it seems that --disable-delete-blank-paragraphs is what slows things down but without it the PDF doesn't look right.
Anyhow, I've hit a wall and at this point this requires further exploration and maybe even look into calibre source to figure out what's going on and why generating the book goes from 10s to 60s in the presence of fonts.

In T271220#6752356, @ifried wrote:

@dmaza Looks like this didn't get estimated yet. Any suggestion for the points it should be assigned? Thanks in advance.

Should this new alias be announced to the wikisource communities? (I guess the same question goes for epub -> epub-3)

@Inductiveload should we close this task then?

In T267079#6729305, @ifried wrote:

Just to clarify, @Samwilson: There's no way we can get data on the ebook exports that time out? Or is there a way? Just want to understand the options for handling this. Thanks in advance!