cmccambridge

Members
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

6 Neutral

About cmccambridge

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @Br0Ser Apologies for missing this a month ago. There's no mechanism for renaming based on content or integrating external code within ocrmypdf-auto today, but you can use it as one stage in a "pipeline." If you've got your own script, you can have ocrmypdf-auto write to an intermediate directory, then have your script pick up new files from the intermediate location, rename or edit them by content, and write to the final output/storage location. I do this with paperless-ng as the next stage of my pipeline. @Chanchalanch Only supports PDFs today... There have been a few requests fo
  2. Excellent, glad to hear that it's working now
  3. @Chad Kunsman Can you try the steps from this post, and see whether you are impacted by the same issue? If that's not it, i.e. if the repository is already correct, please let me know: I'm not on the 6.9 series yet as I haven't hit an opportunity where I could do the upgrade and have time to sort out what breaks... 🤞 Hoping my own container isn't one of the breaking changes.
  4. @Calimero It is, yes! I use my scanner in similar fashion to separate gray versus color documents. Two ideas to try: If there's a shared parent directory that includes all of your scanner profiles, you can just use that shared parent as /input or /output (I run my scanner this way) If there is no shared parent in the "real world" (meaning the real paths that your profiles point to), then you can create one within the container by mapping each input (and each output) directory to a sub-directory within the container, like this: For each input folder, add an
  5. Hello all, BREAKING CHANGE ANNOUNCEMENT! If you have never customized your Mosquitto container, you MUST take action after the next container update! Starting with Mosquitto 2.0.0, the Eclipse project requires explicit configuration to enable listening on non-loopback network interfaces and to allow anonymous (unauthenticated) connections to the MQTT server. This change was made by the Eclipse project to harden their security posture, and is documented in the 2.0.0 release announcement and the official Eclipse migration guide. The unRAID container is ta
  6. Great to hear @sunpower, @nik82! Thanks for letting me know that it's working for you - now I can be confident that I correctly understood the problem I will file an issue in my github backlog here to try and provide an explicit warning (or maybe even an error) from the container logs if it detects permissions that are unlikely to work properly... Since the /output directory is mapped to another location (e.g. appdata or a share), the permissions are set and controlled from outside ocrmypdf-auto... but I can try and at least observe them and provide a recommendation f
  7. Hi @Toskache, @nik82, @sunpower, Apologies for being absent this past week, and thanks for your patience! Thank you for letting me know about this issue. From your description and screenshots, I believe I understand the problem, and have deployed a fix to resolve the "Not Available" message under the Version column on the Docker tab. However, since the bug is related to checking for and applying updates... we may need to be a little more hands-on to repair your individual Docker containers. Details of the bug at the bottom, but first, let's get your Docker conta
  8. @sunpower - It sounds like you got it sorted out, but let me know if you are still having any issues!
  9. Ugh, great catch. Thanks for letting me know @JasonJoel! This bug has been there since I migrated from quay.io in April 2019 and I never noticed, because I made the same edit locally that you've just done... Good news is your fix is exactly correct. I've committed the same to the template repository, so other new installs and folks accidentally pinned at 1.5.8 should receive the update soon as well. Fixed with this PR.
  10. @jonp or @trurl could you move this over to the Docker Containers support thread section? @Squid Anything extra I need to do on the CA side for a second template in my existing repository? Thanks all for all of your help!
  11. Application: mosquitto-unraid Overview: Container for eclipse-mosquitto with Unraid ease-of-use tweaks Docker: https://quay.io/repository/cmccambridge/mosquitto-unraid Application GitHub: https://github.com/cmccambridge/mosquitto-unraid This container is a minimal port of the official Eclipse Mosquitto Docker container with minor tweaks to work more conveniently in Unraid. Breaking Change Announcement (2021-01-20): Starting with Version 2.0.0, this container requires manual configuration to run! See more details below: For details o
  12. Hi @Abigel - couple of thoughts... First and most important: the tesseract OCR engine that is used by ocrmypdf-auto really isn't optimized for handwriting. It's designed for typeset / printed text which has properties that make it "easier to read" like consistent letter shapes, letter spacing, word spacing, line breaks, etc. You can read all the gory details on the tesseract homepage, or explore some of the academic research efforts to extend the engine to handwriting, but the short version to my understanding is: handwriting recognition is a lot harder than recognizing
  13. I'm glad that it's working now for you, @Abigel - I believe I know what the problem was there, and will get an update posted so that other folks don't run into the same problem down the road. Thanks for reporting this! Re: handwriting recognition... This isn't really the intended purpose for tesseract, the OCR program that ocrmypdf-auto is using internally. I have limited success with recognizing block letter handwriting, such as the attached example... you can see that it mostly recognized the block letters (mistook "IS" for "1S"), did similarly OK on mixed upper and lowercase pri
  14. Hi @Abigel, sorry to hear you're having issues... I'm away on vacation at the moment and so don't have access to a computer to debug, but one thing comes to mind to try. The most recent change made to the code was regarding support for multiple languages. Perhaps we introduced a bug there that didn't surface until now. Could you try explicitly setting OCR_LANGUAGES="enu" (or your language of choice) even though it's supposed to work correctly without? Let me know if that changes anything...