synOCR synOCR - GUI für OCRmyPDF

[Yippie]

/var/log/synoscgi.log

Da ich wie gesagt bereits anderweitig vorgegangen bin, kann ich nicht mit Sicherheit sage, ob diese Einträge hier den Upgrade-Fehler beschreiben

2022-08-31T11:16:06+02:00 ISAR synoscgi_SYNO.Core.Package.Installation_1_upload[30410]: pkgverify.cpp:299 Failed to verifypackage, spk=[/volume2/@tmp/upload_tmp.304100] result=[{"action":"prepare","beta":false,"betaIncoming":false,"error":{"code
":289,"description":"spk is not from synology"},"installReboot":false,"package":"synOCR","packageName":"synOCR DSM7","stage
":"prepare","success":false,"version":"1.2.0"}]
2022-08-31T11:16:11+02:00 ISAR synoscgi_SYNO.Core.Package.Installation_1_upgrade[30408]: pkgverify.cpp:299 Failed to verify
package, spk=[/volume2/@tmp/upload_tmp.304100] result=[{"action":"prepare","beta":false,"betaIncoming":false,"error":{"cod
e":289,"description":"spk is not from synology"},"installReboot":false,"package":"synOCR","packageName":"synOCR DSM7","stag
e":"prepare","success":false,"version":"1.2.0"}]
2022-08-31T11:16:12+02:00 ISAR synoscgi_SYNO.Core.Package.Installation_1_upgrade[30571]: docker_compose_start/dockercompose
startworker.cpp:42 file [/var/packages/synOCR/var/docker-compose.yaml] missing[0xD900 manager.cpp:206]
2022-08-31T11:16:12+02:00 ISAR synoscgi_SYNO.Core.Package.Installation_1_upgrade[30571]: docker_compose_start/dockercompose
startworker.cpp:80 Docker compose stop fail with compose file [/var/packages/synOCR/var/docker-compose.yaml].
2022-08-31T11:16:12+02:00 ISAR synoscgi_SYNO.Core.Package.Installation_1_upgrade[30408]: pkguninstall.cpp:252 Failed to rel
ease halt resource before uninstall synOCR [0x2000 bdb_get.c:40]
2022-08-31T11:16:12+02:00 ISAR synoscgi_SYNO.Core.Package.Installation_1_upgrade_SYNO.Docker.Container.PkgProfile_1_remove[
30573]: APIRunner.cpp:1101 AppArmor: change hat Original Hat failed [Operation not permitted]
2022-08-31T11:16:12+02:00 ISAR synoscgi_SYNO.Core.Package.Installation_1_upgrade_SYNO.Docker.Container.PkgProfile_1_remove[
30573]: APIRunner.cpp:1115 AppArmor: change hat failed [Operation not permitted]
2022-08-31T11:16:12+02:00 ISAR synoscgi_SYNO.Core.Package.Installation_1_upgrade_SYNO.Docker.Container.PkgProfile_1_remove[
30573]: APIRunner.cpp:1416 AppArmor: change hat Original Hat failed [Operation not permitted]
2022-08-31T11:16:12+02:00 ISAR synoscgi_SYNO.Core.Package.Installation_1_upgrade_SYNO.Docker.Container.PkgProfile_1_remove[
30573]: APIRunner.cpp:1421 AppArmor: change hat [SYNO.Core.Package.Installation] failed [Operation not permitted]
2022-08-31T11:16:27+02:00 ISAR login.cgi[32625]: login.cpp:174 ERROR: setresgid(-1, 0, -1) [Operation not permitted]

Hier die vermeitlichen Zeilen zum ersten Upgrade-Versuch aus /var/log/packages/synOCR.log

2022/08/31 10:41:08     upgrade synOCR 1.2.0.10 Begin start-stop-status stop
Stopping...
2022/08/31 10:41:08     upgrade synOCR 1.2.0.10 End start-stop-status stop ret=[0]
2022/08/31 10:41:10     upgrade synOCR 1.2.0.10 Begin preupgrade
2022/08/31 10:41:10     upgrade synOCR 1.2.0.10 End preupgrade ret=[0]
2022/08/31 10:41:10     upgrade synOCR 1.2.0.10 Begin preuninst
sed: couldn't open temporary file /etc/sedsZlV8b: Permission denied
2022/08/31 10:41:10     upgrade synOCR 1.2.0.10 End preuninst ret=[0]
2022/08/31 10:41:10     upgrade synOCR 1.2.0.10 Begin /bin/rm -rf /volume1/@appstore/synOCR
2022/08/31 10:41:10     upgrade synOCR 1.2.0.10 End /bin/rm -rf /volume1/@appstore/synOCR ret=[0]
2022/08/31 10:41:10     upgrade synOCR 1.2.0.10 Begin /bin/rm -rf /volume1/@apptemp/synOCR
2022/08/31 10:41:10     upgrade synOCR 1.2.0.10 End /bin/rm -rf /volume1/@apptemp/synOCR ret=[0]
2022/08/31 10:41:10     upgrade synOCR 1.2.0.10 Begin postuninst
2022/08/31 10:41:10     upgrade synOCR 1.2.0.10 End postuninst ret=[0]
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 Begin preinst
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 End preinst ret=[0]
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 Begin /bin/mkdir -p /volume1/@appstore/synOCR -m 755
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 End /bin/mkdir -p /volume1/@appstore/synOCR -m 755 ret=[0]
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 Begin /bin/rm -rf /volume1/@appstore/synOCR
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 End /bin/rm -rf /volume1/@appstore/synOCR ret=[0]
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 Begin /bin/mv -f /volume1/@tmp/synopkg/install.XGZ47b/package /volume1/@appstore/synOCR
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 End /bin/mv -f /volume1/@tmp/synopkg/install.XGZ47b/package /volume1/@appstore/synOCR ret=[0]
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 Begin /bin/rm -rf /var/packages/synOCR
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 End /bin/rm -rf /var/packages/synOCR ret=[0]
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 Begin /bin/mkdir -p /var/packages/synOCR -m 755
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 End /bin/mkdir -p /var/packages/synOCR -m 755 ret=[0]
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 Begin /bin/touch /var/packages/synOCR/installing
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 End /bin/touch /var/packages/synOCR/installing ret=[0]
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 Begin /bin/mv -f /volume1/@tmp/synopkg/install.XGZ47b/INFO /var/packages/synOCR/INFO
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 End /bin/mv -f /volume1/@tmp/synopkg/install.XGZ47b/INFO /var/packages/synOCR/INFO ret=[0]
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 Begin /bin/rm -rf /var/packages/synOCR/scripts
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 End /bin/rm -rf /var/packages/synOCR/scripts ret=[0]
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 Begin /bin/mv -f /volume1/@tmp/synopkg/install.XGZ47b/scripts /var/packages/synOCR/scripts
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 End /bin/mv -f /volume1/@tmp/synopkg/install.XGZ47b/scripts /var/packages/synOCR/scripts ret=[0]
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 Begin /bin/rm -rf /var/packages/synOCR/WIZARD_UIFILES
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 End /bin/rm -rf /var/packages/synOCR/WIZARD_UIFILES ret=[0]
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 Begin /bin/mv -f /volume1/@tmp/synopkg/install.XGZ47b/WIZARD_UIFILES /var/packages/synOCR/WIZARD_UIFILES
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 End /bin/mv -f /volume1/@tmp/synopkg/install.XGZ47b/WIZARD_UIFILES /var/packages/synOCR/WIZARD_UIFILES ret=[0]
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 Begin /bin/rm -rf /var/packages/synOCR/conf
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 End /bin/rm -rf /var/packages/synOCR/conf ret=[0]
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 Begin /bin/mv -f /volume1/@tmp/synopkg/install.XGZ47b/conf /var/packages/synOCR/conf
2022/08/31 10:41:11     upgrade synOCR 1.2.0.12 End /bin/mv -f /volume1/@tmp/synopkg/install.XGZ47b/conf /var/packages/synOCR/conf ret=[0]
2022/08/31 10:41:15     upgrade synOCR 1.2.0.12 Begin postinst
2022/08/31 10:41:15     upgrade synOCR 1.2.0.12 End postinst ret=[0]
2022/08/31 10:41:15     upgrade synOCR 1.2.0.12 Begin postupgrade
2022/08/31 10:41:15     upgrade synOCR 1.2.0.12 End postupgrade ret=[0]
2022/08/31 10:41:16     (system) trigger synOCR 1.2.0.12 Begin start-stop-status stop
Stopping...
chmod: cannot access '/volume1/Scanner/_log/inotify.log': No such file or directory
2022/08/31 10:41:16     (system) trigger synOCR 1.2.0.12 End start-stop-status stop ret=[0]
2022/08/31 10:41:28     upgrade synOCR 1.2.0.12 Begin preupgrade
2022/08/31 10:41:28     upgrade synOCR 1.2.0.12 End preupgrade ret=[0]
2022/08/31 10:41:28     upgrade synOCR 1.2.0.12 Begin preuninst
sed: couldn't open temporary file /etc/sedJXCZkK: Permission denied
2022/08/31 10:41:28     upgrade synOCR 1.2.0.12 End preuninst ret=[0]
2022/08/31 10:41:28     upgrade synOCR 1.2.0.12 Begin /bin/rm -rf /volume1/@appstore/synOCR
2022/08/31 10:41:28     upgrade synOCR 1.2.0.12 End /bin/rm -rf /volume1/@appstore/synOCR ret=[0]
2022/08/31 10:41:28     upgrade synOCR 1.2.0.12 Begin /bin/rm -rf /volume1/@apptemp/synOCR
2022/08/31 10:41:28     upgrade synOCR 1.2.0.12 End /bin/rm -rf /volume1/@apptemp/synOCR ret=[0]
2022/08/31 10:41:28     upgrade synOCR 1.2.0.12 Begin postuninst
2022/08/31 10:41:28     upgrade synOCR 1.2.0.12 End postuninst ret=[0]
2022/08/31 10:41:28     upgrade synOCR 1.2.0.12 Begin preinst
2022/08/31 10:41:28     upgrade synOCR 1.2.0.12 End preinst ret=[0]
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 Begin /bin/mkdir -p /volume1/@appstore/synOCR -m 755
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 End /bin/mkdir -p /volume1/@appstore/synOCR -m 755 ret=[0]
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 Begin /bin/rm -rf /volume1/@appstore/synOCR
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 End /bin/rm -rf /volume1/@appstore/synOCR ret=[0]
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 Begin /bin/mv -f /volume1/@tmp/synopkg/install.Hl3pMl/package /volume1/@appstore/synOCR
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 End /bin/mv -f /volume1/@tmp/synopkg/install.Hl3pMl/package /volume1/@appstore/synOCR ret=[0]
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 Begin /bin/rm -rf /var/packages/synOCR
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 End /bin/rm -rf /var/packages/synOCR ret=[0]
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 Begin /bin/mkdir -p /var/packages/synOCR -m 755
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 End /bin/mkdir -p /var/packages/synOCR -m 755 ret=[0]
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 Begin /bin/touch /var/packages/synOCR/installing
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 End /bin/touch /var/packages/synOCR/installing ret=[0]
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 Begin /bin/mv -f /volume1/@tmp/synopkg/install.Hl3pMl/INFO /var/packages/synOCR/INFO
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 End /bin/mv -f /volume1/@tmp/synopkg/install.Hl3pMl/INFO /var/packages/synOCR/INFO ret=[0]
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 Begin /bin/rm -rf /var/packages/synOCR/scripts
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 End /bin/rm -rf /var/packages/synOCR/scripts ret=[0]
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 Begin /bin/mv -f /volume1/@tmp/synopkg/install.Hl3pMl/scripts /var/packages/synOCR/scripts
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 End /bin/mv -f /volume1/@tmp/synopkg/install.Hl3pMl/scripts /var/packages/synOCR/scripts ret=[0]
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 Begin /bin/rm -rf /var/packages/synOCR/WIZARD_UIFILES
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 End /bin/rm -rf /var/packages/synOCR/WIZARD_UIFILES ret=[0]
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 Begin /bin/mv -f /volume1/@tmp/synopkg/install.Hl3pMl/WIZARD_UIFILES /var/packages/synOCR/WIZARD_UIFILES
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 End /bin/mv -f /volume1/@tmp/synopkg/install.Hl3pMl/WIZARD_UIFILES /var/packages/synOCR/WIZARD_UIFILES ret=[0]
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 Begin /bin/rm -rf /var/packages/synOCR/conf
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 End /bin/rm -rf /var/packages/synOCR/conf ret=[0]
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 Begin /bin/mv -f /volume1/@tmp/synopkg/install.Hl3pMl/conf /var/packages/synOCR/conf
2022/08/31 10:41:29     upgrade synOCR 1.2.0.12 End /bin/mv -f /volume1/@tmp/synopkg/install.Hl3pMl/conf /var/packages/synOCR/conf ret=[0]
2022/08/31 10:41:32     upgrade synOCR 1.2.0.12 Begin postinst
2022/08/31 10:41:32     upgrade synOCR 1.2.0.12 End postinst ret=[0]
2022/08/31 10:41:32     upgrade synOCR 1.2.0.12 Begin postupgrade
2022/08/31 10:41:33     upgrade synOCR 1.2.0.12 End postupgrade ret=[0]
2022/08/31 10:41:33     (system) trigger synOCR 1.2.0.12 Begin start-stop-status stop
Stopping...
chmod: cannot access '/volume1/Scanner/_log/inotify.log': No such file or directory
2022/08/31 10:41:33     (system) trigger synOCR 1.2.0.12 End start-stop-status stop ret=[0]

 

[Thonav]

Habs nachgestellt - gleicher Fehler. @geimist - da scheint es ein Problem zu geben.

 

[Nico93]

Vielen Dank für den Tipp
Ich will und kann ja das Rad auch nicht neu erfinden. Damit haben wir ja schon eine schöne Grundlage. Das wird aber nichts mehr für die aktuelle Beta.

Ich hab es mir jetzt noch nicht angesehen: wie werden bereits abgearbeiteten Mails gehandhabt?
Gibt es da einen Cache oder werden die Quellmails verschoben? Ich vermute, es läuft nur über die Zeitstempel, korrekt?

Gerne, dafür nicht
Ich glaube wir haben eher für dein Projekt zu danken.

Ich habe es eben einmal getestet. Im Standard werden die E-Mail nicht verschoben. Jedoch werden dann die Anhänge/Mails auch jedes mal erneut heruntergeladen. Es gibt ein Parameter mit dem man die verarbeiteten E-Mail verschieben kann. "--delete --delete-copy-folder=DELETE_COPY_FOLDER"

Ich nutze aktuell ein extra Postfach und lasse somit die E-Mail immer direkt mit dem Parameter "--delete" löschen.

 

[Tommes]

@geimist
Das mit der Änderung im Start-Stop-Script hatte ich garnicht mitbekommen. Ich weiß nur, das vieles in den Install-Scripten unter DSM7 wegen fehlender Berechtigungen scheitert.

Ich schau mir das Paket heut Abend mal an. Für den Moment habe ich aber auch noch keine Idee, woran es liegen könnte. Außer das du evtl. Dateieechte in dem Paket geändert hast und der DSM deshalb anfängt zu maulen.

@all
Welche DSM Version verwendet ihr? Nicht zufällig die 7.1.1 RC?

 

[Thonav]

7.1.1 RC

 

[Tommes]

@Thonav
Hm… wäre ja nichts Neues, wenn Synology mal wieder einen zum Besten gegeben hat um uns Developer zu ärgern. Ich hab die 7.1.1 RC bei mir noch nicht geladen und eigentlich hatte ich das auch nicht vor. Mal sehen…

 

[Thonav]

Ihr macht das schon

 

[geimist]

Ich hab es erstmal zurückgezogen - sorry, wegen des Ärgers.

 

[Yippie]

@all
Welche DSM Version verwendet ihr? Nicht zufällig die 7.1.1 RC?

DSM 7.1-42661 Update 4

 

[Yippie]

Ich hab es erstmal zurückgezogen - sorry, wegen des Ärgers.

Absolut kein Problem, man kann ja über alles reden und ggf. wird einem hier geholfen

 

[Yippie]

Kleiner Feature-Request:

Ich nutze fleißig die YAML Datei mit mittlerweile mehreren Regeln. Manches mal jedoch treffen aus dieser Datei mehrere Regeln zu, die ich bisher aber nicht exakt durch subrules voneinander abgrenzen konnte.

Wäre es möglich eine YAML-Option zu ergänzen, die sinngemäß lautet: continue: [true|false]?
Was soll dies bringen? Sobald eine der vielen Regeln zutrifft, soll die erste die "gewonnen" hat und bei der continue: false verwendet wurde, durchlaufen und alle anderen nicht mehr weiter verfolgt werden.

Bspw.

RIESTER_1:
    tagname: "§yocr4-§mocr-§docr Versicherungsschein"
    tagname_RegEx:
    targetfolder: "/Riester/"
    condition: all
    continue: false
    subrules:
...
RIESTER_2:
    tagname: "§yocr4-§mocr-§docr Information"
    tagname_RegEx:
    targetfolder: "/Riester/"
    condition: all
    subrules:
...

Das continue oben soll bewirken, dass die Regel RIESTER_2 nicht mehr ausgeführt werden soll, sobald RIESTER_1 entsprechenden den festgelegten Optionen zutrifft.
Ist dies nicht der Fall, dann werden nachfolgende Regeln wie bisher durchlaufen. Fehlt continue, das soll per Default true gelten um bestehende YAML-Dateien nicht weiter zu beeinflussen. Siehe Regel RIESTER_2.

Gerne aber auch einen anderen Optionsnamen vorschlagen...mir ist gerade nichts Besseres eingefallen.

 

[geimist]

Ja, ja - die Regelpriorisierung. Da bist du nicht der Erste, der sich das wünscht. Dein Vorschlag geht nicht 1:1 umzusetzen, da die Regeln ja nach Regelnamen sortiert werden (das müsste man bei dieser Form mit beachten). Da gab es auch noch granularere Einstellwünsche. Das wird als komplexer und ich habe immer noch keine klare Vision davon.

So etwas in der Form ist aber für die Zukunft geplant.

 

[Yippie]

D.h. durch entsprechende Regelnamen könnte ich zumindest ein gewisse Reihenfolge erreichen?

Also quasi 1_ würde vor 2_ ausgewertet werden? Auch wenn 2_ in der YAML Datei, nach 2_ definiert wurde?

 

[geimist]

Jain. In der Umsetzung sieht es so aus, dass die Regeln nach Regelname alphabetisch absteigend abgearbeitet werden und neue Funde der Tagliste immer vorangesetzt werden, sodass letztendlich die alphabetische Reihenfolge gewährleistet ist. Bisher stand hier für die User lediglich die Reihenfolge im Fokus, weshalb die genaue Umsetzung irrelevant war. In deinem Fall geht das darüber hinaus und du solltest diesen Hintergrund mit bedenken.

PS: Bitte bedenke, dass Regelnamen prinzipiell nicht mit einer Zahl beginnen dürfen.

 

[Yippie]

Hi!

Hab Mal wieder ein Problem mit synOCR. Bitte nicht schlagen Verwende synORC 1.2.0

Ich habe in meiner YAML folgendes eingestellt:

LV_1:
    tagname: "§yocr4-§mocr-§docr Lebensversicherung"
    tagname_RegEx:
    targetfolder: "/Lebensversicherung/"
    condition: all
 
RIESTER_1:
    tagname: "§yocr4-§mocr-§docr Versicherungsschein"
    tagname_RegEx:
    targetfolder: "/Riester/"
    condition: all
...

Laut Log findet synOCR auch ein Datum 11.12.2021 im Content, aber verwendet dieses nicht für den Dateinamen (Auszug):

PROCESSING:   ➜ 2021-12-11 Versicherungsschein.pdf (Wed Aug 31 16:33:20 CEST 2022)
                  temp. target file: /tmp/tmp.k1gORPaHDf/2021-12-11 Versicherungsschein.pdf

              ➜ OCRmyPDF-LOG:
                WARNING: Error loading config file: .dockercfg: $HOME is not defined
                reading file from standard input
                Start processing 3 pages concurrently
                    1 skipping all processing on this page
                    2 skipping all processing on this page
                    3 skipping all processing on this page
                Postprocessing...
                Some input metadata could not be copied because it is not permitted in PDF/A. You may wish to examine the output PDF's XMP metadata.
                Optimize ratio: 1.22 savings: 18.0%
                Output sent to stdout
              ← OCRmyPDF-LOG-END

                target file (OK): /tmp/tmp.k1gORPaHDf/2021-12-11 Versicherungsschein.pdf

              ➜ search tags and date:
                source for tags is yaml based tag rule file [/volume1/Scanner/Eingabe/profiles/global.yml]
                validate the integrity of yaml-file:

                search by tag rule: "RIESTER_2" ➜
                  ➜ condition:        all
                  ➜ tag:              §yocr4-§mocr-§docr Information
                  ➜ destination:      /Riester/
                          >>> Rule is not satisfied

                search by tag rule: "RIESTER_1" ➜
                  ➜ condition:        all
                  ➜ tag:              §yocr4-§mocr-§docr Versicherungsschein
                  ➜ destination:      /Riester/
                          >>> Rule is satisfied
...
                rename tag is: "§yocr4-§mocr-§docr Versicherungsschein"

                  Using date format: 1 (1 = dd mm [yy]yy; 2 = [yy]yy mm dd; 3 = mm dd [yy]yy)
                  Dates found: 10
                  check date (dd mm [yy]yy): 11.12.2021
                  ➜ valid
                      day:  11
                      month:12
                      year: 2021
              ➜ renaming:
                  apply renaming syntax ➜ §yocr4-§mocr-§docr Versicherungsschein
              ➜ edit metadata FAILED! - exiftool not found! Please install it over cphub.net if you need it
              ➜ move to category directory
                  tag directory "/Riester/" exists? ➜  OK [subfolder target dir]
                  target:   /volume1/Scanner/Ausgabe//Riester/§yocr4-§mocr-§docr Versicherungsschein.pdf
                  set a hard link
              ➜ Adapt file date (Source: Source file)

              ➜ delete source file
                  INFO: (PushBullet-TOKEN not set)

Der Dateiname wie folgt ausgegeben: "§yocr4-§mocr-§docr Versicherungsschein.pdf" anstatt wie erwartet: "2021-12-11 Versicherungsschein.pdf".

Woran liegt das? Bin für jeden Tipp dankbar...

Ach ja, was macht synOCR, wenn im Text ein Datum wie 25. August 2022 vorhanden ist? Wird dies erkannt und entsprechend umgesetzt? Ich glaube nein, denn in meinem konkreten Fall wurde dieses Datum nicht ins Log geschrieben, sondern ein Datum, welches auf eine der anderen Seite erkannt wurde: 01.01.2021, aber in meinem Fall komplett falsch von synOCR verwendet wird.

Kann man zusätzlich zu den Tags "§yocr4-§mocr-§docr" ein Fallback setzen, dass wenn kein Datum gefunden wurde, das Erstell-/Änderungs-Datum der Datei verwendet wird?

Edit: Irgendetwas läuft hier falsch: Eine weitere Regel in meiner YML-Datei, die folgende Optionen hat:

CITES_1:
    tagname: "Cites DE-DEG§tagname_RegEx"
    tagname_RegEx: "[[:digit:]]{6}-[[:digit:]]{2,}"
    targetfolder: "/Cites/"
    condition: all
    subrules:
    - searchstring: "EUROPEAN UNION"
      searchtyp: is
      isRegEx: false
      source: content
      casesensitive: false
    - searchstring: "[[:digit:]]{6}-[[:digit:]]{2,}"
      searchtyp: contains
      isRegEx: true
      source: content
      casesensitive: false

wird korrekt angewendet, jedoch der Dateiname, der dann eigentlich final "Cites DE-DEG200424-41.pdf" lauten soll, wird urplötzlich als "200424-41.pdf" verwendet. Das hat jedoch schon Mal korrekt funktioniert.. synOCR ist immer noch Version 1.2.0.

Siehe Log:

search by tag rule: "CITES_1" ➜ 
                  ➜ condition:        all
                  ➜ tag:              Cites DE-DEG§tagname_RegEx
                  ➜ destination:      /Cites/
                  ➜ RegEx for tag:    [[:digit:]]{6}-[[:digit:]]{2,}
                          >>> Rule is satisfied

                              ➜ search RegEx for tag ➜ 200424-41

                rename tag is: "200424-41"

                  Using date format: 1 (1 = dd mm [yy]yy; 2 = [yy]yy mm dd; 3 = mm dd [yy]yy)
                  Dates found: 2
                  check date (dd mm [yy]yy): 22.08.2019
                  ➜ valid
                      day:  22
                      month:08
                      year: 2019
              ➜ renaming:
                  apply renaming syntax ➜ 200424-41

Ich bin jetzt irgendwie ratlos.

 

[geimist]

Die Variablenbeachtung innerhalb der Tags wurde erst mit der aktuellen Releasphase implementiert.
Wenn du die aktuelle Beta wieder einspielst (ist ja jetzt wieder die Version 1.2.0.11), dann werden auch ausgeschriebene Daten erkannt.

 

[Yippie]

OH MAN, WIE BLÖD VON MIR - DANKE für den heißen TIPP!

 

[Yippie]

Die Variablenbeachtung innerhalb der Tags wurde erst mit der aktuellen Releasphase implementiert.
Wenn du die aktuelle Beta wieder einspielst (ist ja jetzt wieder die Version 1.2.0.11), dann werden auch ausgeschriebene Daten erkannt.

Mit dieser Version ist alles wieder OK, auch die Frage nach dem Fallback anhand des Datinamens erübrigt sich damit, denn genau das funktioniert mit dieser Version perfekt ;-)

 

[commanderi]

Hey Leute,

ich weiß gerade nicht was bei mir los ist, es werden keine Dokumente mehr aus dem Input Ordner abgearbeitet bzw. es passiert nichts. LOG habe ich Euch mal angehängt. Jemand ne Idee was falsch ist? Habe eigentlich nichts verändert.

-----------------------------------
| ==> installation info <== |
-----------------------------------

synOCR-user: root
synOCR-user is admin: yes
synOCR-version: 1.2.0
Architecture: x86_64
DSM-build: 23824
Device: 716plusII (4275539728)
current Profil: default
DB-version: 5
used image (created): jbarlow83/ocrmypdf:latest (2022-08-15T00:14:34)
used ocr-parameter (raw): frd -l deu+eng
OCR-arg 1: -
OCR-arg 2: frd
OCR-arg 3: -l
OCR-arg 4: deu+eng
ocropt_array: - frd -l deu+eng
search prefix:
replace search prefix: yes
renaming syntax: §y-§m-§d_§tag_§tit
Symbol for tag marking: #
Document split pattern:
Date search method: use standard search via RegEx
source for filedate: now
ignored dates by search: 2021-02-29;2020-11-31
PATH-Variable: /sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/opt/usr/bin:/usr/syno/synoman/webman/3rdparty/synOCR/bin
Docker test: OK
DSM notify to user: admin
Loglevel: debug
max. count of logfiles: 100000
Source directory: /volume1/DMS/_INPUT/
Target directory: /volume1/DMS/_OUTPUT/
Files are deleted immediately! / No valid directory [/]
rotate backupfiles after: (purge backup deactivated)



----------------------------------
| ==> Funktionsaufrufe <== |
----------------------------------
show files in INPUT with transcoded special characters

@eaDir$
Scan09-06-2022-100316.pdf$
(pages counted with pdfinfo)

PROCESSING: ➜ Scan09-06-2022-100316.pdf (Tue Sep 6 10:05:03 CEST 2022)
temp. target file: /tmp/tmp.BosMRiJUIf/Scan09-06-2022-100316.pdf

[runtime up to now: 00:00:00]


➜ OCRmyPDF-LOG:
usage: ocrmypdf [-h] [-l LANGUAGES] [--image-dpi DPI]
[--output-type {pdfa,pdf,pdfa-1,pdfa-2,pdfa-3,none}]
[--sidecar [FILE]] [--version] [-j N] [-q] [-v [VERBOSE]]
[--title TITLE] [--author AUTHOR] [--subject SUBJECT]
[--keywords KEYWORDS] [-r] [--remove-background] [-d] [-c]
[-i] [--unpaper-args UNPAPER_ARGS] [--oversample DPI]
[--remove-vectors] [-f] [-s] [--redo-ocr] [--skip-big MPixels]
[--pages PAGES] [--max-image-mpixels MPixels]
[--pdf-renderer {auto,hocr,sandwich,hocrdebug}]
[--rotate-pages-threshold CONFIDENCE]
[--pdfa-image-compression {auto,jpeg,lossless}]
[--fast-web-view MEGABYTES] [--plugin PLUGINS] [-k]
[--tesseract-config CFG] [--tesseract-pagesegmode PSM]
[--tesseract-oem MODE] [--tesseract-thresholding METHOD]
[--tesseract-timeout SECONDS] [--user-words FILE]
[--user-patterns FILE] [-O {0,1,2,3}] [--jpeg-quality Q]
[--png-quality Q] [--jbig2-lossy]
input_pdf_or_image output_pdf
ocrmypdf: error: unrecognized arguments: - -
← OCRmyPDF-LOG-END


[runtime up to now: 00:00:09]

┖➜ failed! (target file is empty or not available)
➜ purge logfiles:
➜ purge backup deactivated



-----------------------------------
| ==> synOCR ENDE <== |
-----------------------------------

 

[geimist]

used ocr-parameter (raw): frd -l deu+eng

Vor dem OCR-Parameter frd hast du den Bindestrich vergessen oder gelöscht.

-frd -l deu+eng