Ich erhalte aktuell häufig o.g. Fehler.
Das scheint vor allem bei grossen Dateien aufzutreten.
Aktuell versuche ich Dateien mit 77 Seiten und weitere mit 577 oder 718 Seiten in paperless zu bekommen.
Man findet zu diesem Thema Beiträge, dass man einen ocrmypdf-custom- Parameter angeben soll.
Das scheint aber wirkungslos zu sein. Entspricht leider auch Kommentaren im Netz.
Any ideas ?
Ja. Das liegt daran, dass das PDF Format nur ein „Container“ und kein Standard per se ist. Dokumente mit dem Fehler entsprechen in der „Hülle“ dem PDF Format, während im Dokumenteninneren Kraut und Rüben herrscht. Zumindest aus Perspektive einer strengen Validierung wie sie das Modul in Paperless mitbringt.
Lösungsoptionen:
Beim Rendern eines PDF darauf achten, dass ein ordentliches oder standardisiertes PDF erstellt wird. (Sofern darauf Einfluss herrscht). Alternativ: Dokument in einem PDF Editor öffnen, erneut abspeichern (hilft nicht immer).
Das PDF im Terminal/ Konsolemit folgendem Befehl reparieren:
gs
-o cleaned.pdf
-sDEVICE=pdfwrite
-dCompatibilityLevel=1.4
-dPDFSETTINGS=/prepress
-dNOPAUSE -dBATCH
Test.pdf
Stelle dabei sicher, dass ghostscriot lokal installiert ist. Das funktioniert garantiert.
Sollte das Problem häufig auftreten, automatisiere den Reparaturvorgang vor import. zB: Lege alle Dokumente in einem getrennten Ordner ab, lasse sie automatisch validieren und verschiebe sie nach erfolgreicher Prüfung weiter den consume Ordner.
Oder: bastle dir einen docker Container mit Ghostscript an Bord und jage alle als defekt markierten Dokumente da durch.
Usw.
Die Validierung in paperless bzw. des Ghostscript modules wurde kürzlich strenger. Das zwingt zu Genauigkeit. PDF werden immer wieder am Standard vorbei zusammen geklöppelt. Ist ein bisschen nervig
Hilfreich wäre zuerst einmal eine detailliertere Fehlerbeschreibung. Wo kommen die PDFs her? Passiert der Fehler beim Verarbeiten der Originaldokumente oder nachdem der OCR-Lauf durchgeführt wurde? Kannst du eine der fehlerhaften PDFs zum Testen zur Verfügung stellen?
Es sind unterschiedliche Dateien:
Typ1: Gescannte Service-Manuale aus den 80ern; viele Grafiken, definitiv NICHT elektronisch entstanden. Die texterkennung steht gar nicht im Vordergrund, sondern die Archivierung.
Typ2: ähnlich Typ1; ein sog. „illustrated parts catalog“ mit vielen Grafiken und Tabellen. Sicherlichdie hohe Schule der OCR. Auch hier stelle ich keine Ansprüche an die Texterkennung
Typ3: Ein Motor-Wartungs-Manual, welches vermutlich elektronisch entstanden ist.
P.S: Ich kann die originale-PDF anscheinend nicht hochladen.
interessanterweise funktioniert ein ocrmypdf auf einem anderen rechner einwandfrei ohne Fehlermeldung
Allerdings habe ich nicht alle Parameter aus dem paperless Protokoll übernommen sondern nur ein nacktes 'ocrmypdf input output gemacht.
Wäre es möglich, dass der LXC-Container ein Speicherproblem hat?
Das ist sogar sehr gut möglich. Eine Synology mit Standard 2GB wird von komplexen PDFs auch in Fehler getrieben, welche mit mehr Speicher nicht mehr auftreten.
Hmm.
Paperless läuft auf einem Proxmox LXC-Container - also docker container innerhalb Proxmox
df -h ergibt für „/“ 13G frei, für HDD 50% (dort ist paperless gespeichert)