jbarlow83

This is probably/hopefully resolved as of v13.1. ocrmypdf now recognizes if one of its child workers has crashed or killed by OOM. Previously this kind of error handling only worked...

>However, if fixing this problem is not a priority, I don't have a way to reproduce this so it's not that easy to investigate, not that it's the sort of...

First, v13.1 does fix at least some versions of this issue, since a failed child process (which can be simulated easily) would definitely hang ocrmypdf and that is fixed now....

Tests: Explored the possibility that that `tls.pageno` - used to ensure page numbers are logged correctly in error messages - is involved since it involves thread local storage. Issue still...

Note `-j12` aggravates the issues; seems related to a worker process ending up without any work to do. Try `TqdmConsole` lock around write, flush - deadlocks Try `with logging_redirect_tqdm(): result...

Can't reproduce on ocrmypdf 13.4.4 and gs 9.56. The PDF has been modified such that the page image shows the same reduction and replication. i.e. we are not repeating the...

@stumpylog If you run `ocrmypdf --skip-text --clean --deskew --rotate-pages --rotate-pages-threshold 12 --keep-temporary-files input.pdf output.pdf` on the arm64 box, after ocrmypdf finishes it will print the location of its temporary intermediate...

Does this still occur with more recent arm64 libraries?

Thanks for the info

>Why is that and, naively spoken: is it not possible to keep the existing page images and just swap the underlying text? By using `--force-ocr`, you are specifically asking for...