synOCR synOCR - GUI für OCRmyPDF

[geimist]

Ohne dem Zurückspielen eines ebenfalls fehlerhaften Backups sollte eine Neueinrichtung problemlos funktionieren.

Falls der Fehler dennoch auftritt, würde ich mir die Konfigurations-DB gern einmal ansehen.

 

[geimist]

Es gibt mal wieder eine neue Beta (v1.5.99.3).

Downlaod synOCR BETA

• Es wurde ein Fehler behoben, der verhinderte, dass ein & in der YAML-Umbenennungssyntax verwendet werden konnte
• Endlich konnte ein FolderPicker eingebaut werden. Das macht die Einrichtung wesentlich Anwenderfreundlicher und sicherer.
  (Es werden nur die Ordner angeboten, auf die der eingeloggt User Zugriff hat.)

 

[geimist]

Ich suche Tester mit ARM-CPU (aarch64) ​

synOCR lief ja bis Version 1.4.5 bereits auf diesen Geräten. In Version 1.5 gab es aber eine Inkompatibilität, die ich jetzt hoffentlich auflösen konnte.
Mit einem kurzes Feedback, ob es mir dieser Version wieder läuft, könntet ihr mich sehr unterstützen (ich habe leider keine passende DS).

Wichtig beim Testen ist, dass ihr nicht nur das SPK installiert, sondern auch ein PDF verarbeiten lasst. Erst dabei wird sich der Erfolg zeigen.

Hier das entsprechende SPK.

Vielen Dank

 

[kshb]

Mit dem Update werden die &-Zeichen bei mir wieder mit ausgegeben. Besten Dank

 

[DaveR]

I just installed Container Manager and synOCR on my DS218 which is aarch64. There's a lot I like about the UI - I might even copy of some it for my future packages . A few thoughts I had were it would be nice if:

1. The folder picker allowed creating the required subfolders (I had to leave the UI and open File Station to create the folders).
2. Instead of the folder picker showing "Select the folder" it showed "Select the input folder" or "Select the output folder" etc depending on which button was clicked in the UI.
3. If the "synOCR Running..." page showed which file it was currently processing. For me it should be processing 3 files: 27MB, 50KB and 1.7MB and I can't tell if it's stuck or still processing. The "wait icon" froze after a few revolutions (due to a browser plugin I have that lets gif files only play once). Okay, as I typed all this it has just finished processing - without any errors in the UI.

file_processing.log shows it failed on the 27MB pdf file:

[2026-05-14_10-40-36] SOURCE: Smashing Photoshop CS5.pdf
                      ➜ unsuccessful

And (the attached) synOCR_2026-05-14_10-40-35.log shows it never even tried to process the other 2 pdf files.

EDIT I just got an email saying:

Container synOCR in Container Manager stopped unexpectedly. Please select synOCR on the Container page, click the Details button, and go to the Log tab for details.

From DS218

but there is no synOCR container in Container Manager.


Curiously synOCR didn't show in the community section of package center. But I'm yet to figure out if that's an issue with my package server or the INFO file in the synOCR spk file.

EDIT2 I see the problem. This noarch BETA_v1.5.99.5 spk file is not stored on your GitHub repo.

 

[geimist]

The folder picker allowed creating the required subfolders (I had to leave the UI and open File Station to create the folders).

That's true, that would be consistent. I'll have to think about that. In that case, it should only be optional.

Instead of the folder picker showing "Select the folder" it showed "Select the input folder" or "Select the output folder" etc depending on which button was clicked in the UI.

Good idea

Container synOCR in Container Manager stopped unexpectedly. Please select synOCR on the Container page, click the Details button, and go to the Log tab for details.

Have a look here: https://github.com/geimist/synOCR/issues/67

If the "synOCR Running..." page showed which file it was currently processing. For me it should be processing 3 files: 27MB, 50KB and 1.7MB and I can't tell if it's stuck or still processing. The "wait icon" froze after a few revolutions (due to a browser plugin I have that lets gif files only play once). Okay, as I typed all this it has just finished processing - without any errors in the UI.

I'd never thought of that before, since synOCR usually runs in the background (ideally triggered by inotify).
That would definitely be nice—I'll add it to the list.

And (the attached) synOCR_2026-05-14_10-40-35.log shows it never even tried to process the other 2 pdf files.

Please try installing Python 3.9 as well. I just noticed in the code that there was a different requirement for aarch64.
(was fixed in v1.4.2)

Perhaps preinst would be a good place to look into this further and inform the aarch64 user.

Curiously synOCR didn't show in the community section of package center. But I'm yet to figure out if that's an issue with my package server or the INFO file in the synOCR spk file.

Maybe because this version is now marked as noarch again?
I just wanted to know if it works with aarch64 now. If so, the next beta will be uploaded to GitHub as noarch.

 

[geimist]

I've added a test to preinst and preupgrade: synOCR_DSM7_local_BETA_v1.5.99.6.spk
Please try it again (and make sure to install Python version 3.9 or later).

If it works, I'll upload the build to GitHub.

Thank you very much for testing.

 

[DaveR]

Your python 3 check in preinst and preupgrade looks good. At first I thought why not add python3 as a "install_dep_packages" in the INFO file like install_dep_packages="python>=3.7.0-0" but that won't work because:

1. Python3 is only required for aarch64.
2. The various python3 package version have different names: Python3, py3k, python311 etc.

I tried upgrading to the latest beta without python3 installed just to see the message, and it looks good.


With python3 installed synOCR_DSM7_local_BETA_v1.5.99.6.spk works on a Synology with an aarch64 CPU. All 3 files got processed and output to the OUTPUT folder with their modified date pre-pended to their filenames. And the OUTPUT files are a bit smaller than the original files in the BACKUP folder.

Though I'm not sure what exactly it did, or does? I guess I should go to page 1 and read the original post.

 

[geimist]

Though I'm not sure what exactly it did, or does? I guess I should go to page 1 and read the original post.

Sure—we'll talk next year once you've read through it

… All 3 files got processed and output to the OUTPUT folder with their modified date pre-pended to their filenames. And the OUTPUT files are a bit smaller than the original files in the BACKUP folder.

OCRmyPDF also makes a few adjustments to the file. Ultimately, the PDF is rewritten.
With the OCR parameter --keep_hash, the original is preserved. In this case, the file is merely renamed and sorted according to rules based on the text extract (the document with the OCR layer is discarded here). In this scenario, a scanned PDF remains unsearchable afterward.

I've published the version on GitHub. Then we'll see how it works with noarch.

Thank you very much for testing it.

 

[DaveR]

It has appeared in package center.

 

[DaveR]

Does synOCR for DSM 7 work on Synology models with a i686 or armhf CPU platform? Because your synOCR DSM 7 spk file with "noarch" will appear in package center for x86_64, aarch64, i686 and armhf models.

For the last 7 days my package source logs show 68 requests from Synology models with DSM 7.x and a armhf CPU.

  17     monaco_ds216play
  16     armada375_ds215j
  11     armada370_213j
  10     armada38x_ds116
  6      armada38x_ds216
  4      armada38x_ds216j
  2      armada38x_ds218j
  2      alpine4k_ds215+
  68 TOTAL

That's 11.5% of the models, and 24% of the platforms that request the package list are armhf.

 

[DaveR]

Okay, I just realised docker and container manager aren't available for armhf or i686 models.

So synOCR should exclude them, instead of using arch="noarch" there are 2 choices:

1. Change arch="noarch" to arch="x86_64 aarch64"

My package server already supports multiple arches.​

2. Or add exclude_arch

arch="noarch"
exclude_arch="armhf i686"

I'm updating my package server to support exclude_arch​

 

[geimist]

I updated the INFO file to set arch="x86_64 aarch64" and uploaded it to GitHub.