synOCR synOCR - GUI für OCRmyPDF

[mamema]

oh... 1.2 sagtest Du. hab noch 1.1.2. Wenn Du danach Putzfrauen Tasks eingebaut hast, dann umso besser....hmm ist BETA....

 

[geimist]

nö, automatische updates mache ICH nicht (kein watchtower), es sei den DU machst was

Nur indirekt, sofern gewünscht:

hmm ist BETA...

Nein, keine Beta. Ich muss nur die Pakete für cphub unterscheiden, um sie für DSM6 und DSM7 differenziert bereitstellen zu können. Daher ist die Version für DSM6 (deren Nutzen inzwischen in der Minderheit sind) aber Version 1.2.0 die 'Beta'.

Die aktuelle Version findest du (derzeit nur) auf meinem Server (Link in Signatur).

 

[Stationary]

Ich habe auch noch 1.1.2, da muß ich ja mal nachschauen. Würde es eigentlich etwas ändern, wenn ocrmypdf bereits manuell im Docker installiert vorliegt? Oder würde das jedesmal wieder gelöscht?

Die Funktion “Dockerimage aktuell halten” sehe ich aber in meiner 1.1.2 auch.

 

[geimist]

Würde es eigentlich etwas ändern, wenn ocrmypdf bereits manuell im Docker installiert vorliegt?

Nein. Darum brauchst du dich nicht kümmern.

Die Funktion “Dockerimage aktuell halten” sehe ich aber in meiner 1.1.2 auch.

Ja, die gibt es schon länger. Das war auf die Aussage von @mamema bezogen. Die Bereinigung ist aber in v1.2.0 hinzugekommen. Die läuft automatisch, sobald man die automatischen Updates für OCRmyPDF aktiviert hat. Die Bereinigung bezieht sich aber auch nur auf die Images von OCRmyPDF.

 

[Stationary]

Kann ich beim “manual install” eigentlich die 1.2 einfach über die 1.1.2 drüberinstallieren oder muß ich die 1.1.2 erst entfernen?

 

[geimist]

einfach drüber damit

 

[Stationary]

Ich schau mal, ob ich Dir mal das language file auf italienisch übersetzen kann. Ich lade es mir heute abend mal herunter.

 

[geimist]

bellissimo

Nehme bitte die Vorlage aus der Master-Branch:
https://git.geimist.eu/geimist/synOCR/src/branch/master/APP/ui/lang

 

[peterhoffmann]

Nach dem Absetzen von:

docker images

bekam ich folgendes Ergebnis (bereinigt von anderen Images):

REPOSITORY                TAG       IMAGE ID       CREATED         SIZE
jbarlow83/ocrmypdf        latest    67c585eb88f0   10 days ago     638MB
jbarlow83/ocrmypdf        <none>    521ba533d999   2 weeks ago     638MB
jbarlow83/ocrmypdf        <none>    9385c2136db7   3 weeks ago     636MB
jbarlow83/ocrmypdf        <none>    a4a4211e6c96   4 weeks ago     636MB
jbarlow83/ocrmypdf        <none>    f4ff804b466d   6 weeks ago     636MB
jbarlow83/ocrmypdf        <none>    6f4e6fa98f94   7 weeks ago     630MB
jbarlow83/ocrmypdf        <none>    db17ee6702af   7 weeks ago     630MB
jbarlow83/ocrmypdf        <none>    5244818c301e   2 months ago    630MB
jbarlow83/ocrmypdf        <none>    713959d5f2d9   2 months ago    630MB
jbarlow83/ocrmypdf        <none>    3600ac0bc328   2 months ago    630MB
jbarlow83/ocrmypdf        <none>    a4b74d75ba6a   4 months ago    628MB
jbarlow83/ocrmypdf        <none>    c239c2288022   4 months ago    627MB
jbarlow83/ocrmypdf        <none>    27cfd5e985c4   5 months ago    626MB
jbarlow83/ocrmypdf        <none>    51cd2780d874   5 months ago    626MB
jbarlow83/ocrmypdf        <none>    ba0fc8e5d97b   6 months ago    627MB
jbarlow83/ocrmypdf        <none>    f75da250aa41   6 months ago    627MB
jbarlow83/ocrmypdf        <none>    29c50aefaa40   7 months ago    627MB
jbarlow83/ocrmypdf        <none>    d9e0aabb0aee   8 months ago    438MB
jbarlow83/ocrmypdf        <none>    ac0e6d24182d   8 months ago    435MB
jbarlow83/ocrmypdf        <none>    417057235678   8 months ago    435MB
jbarlow83/ocrmypdf        <none>    3a8334f20244   10 months ago   431MB
jbarlow83/ocrmypdf        <none>    ce280abb7ed9   10 months ago   431MB
jbarlow83/ocrmypdf        <none>    b1f22aca84c3   11 months ago   459MB
jbarlow83/ocrmypdf        <none>    5dba8e6fbf58   12 months ago   459MB
jbarlow83/ocrmypdf        <none>    3584ec51e297   13 months ago   456MB
jbarlow83/ocrmypdf        <none>    f01e3f25e17c   13 months ago   459MB
jbarlow83/ocrmypdf        <none>    efe214a60fad   14 months ago   456MB
jbarlow83/ocrmypdf        <none>    5791039e6a2b   15 months ago   454MB
jbarlow83/ocrmypdf        <none>    20299daa638b   15 months ago   454MB
jbarlow83/ocrmypdf        <none>    d58d6ec85dcd   16 months ago   513MB
jbarlow83/ocrmypdf        <none>    524bf326eeae   16 months ago   513MB
jbarlow83/ocrmypdf        <none>    4049ce77b617   17 months ago   513MB
jbarlow83/ocrmypdf        <none>    1ba50d569cc2   17 months ago   514MB
jbarlow83/ocrmypdf        <none>    bdc1471db76f   18 months ago   514MB
jbarlow83/ocrmypdf        <none>    5ac3e80c78b9   19 months ago   514MB
jbarlow83/ocrmypdf        <none>    48d11b2ce1a5   19 months ago   508MB
jbarlow83/ocrmypdf        <none>    ffe5e15ca52d   20 months ago   481MB
jbarlow83/ocrmypdf        <none>    ed513e9b1370   20 months ago   480MB
jbarlow83/ocrmypdf        <none>    cab97f9a4d32   21 months ago   480MB
jbarlow83/ocrmypdf        <none>    a7ae53041e9a   21 months ago   480MB
jbarlow83/ocrmypdf        <none>    8c2b93c69cd7   2 years ago     447MB

Mein Verzeichnis /volume1/@Docker hat rund 22,5GB.

 

[Stationary]

Kannst Du die löschen? Oder räumt die 1.2 von synocr dann automatisch alle alten auf?

 

[geimist]

Nach dem Absetzen von: docker images bekam ich folgendes Ergebnis (bereinigt von anderen Images):

@peterhoffmann
Nutzt du die Version 1.2.0?
Ist die Option zum automatischen Aktualisieren in der GUI gesetzt?

 

[peterhoffmann]

Ich habe sie nun so gelöscht:

docker images -f dangling=true  | awk '{print $3}'  | xargs docker rmi

(ohne Gewähr)

 

[geimist]

Kannst Du die löschen? Oder räumt die 1.2 von synocr dann automatisch alle alten auf?

Sofern beide obigen Bedingungen erfüllt sind, wird nach jeder Updatesuche (1x am Tag) die Bereinigung durchgeführt. Da synOCR nicht übergriffig sein soll, werden nur OCRmyPDF-Leichen gelöscht. Das läuft hier so (entspricht ja grob Peters Version):
docker rmi -f $(docker images -f "dangling=true" --format "{{.ID}}:{{.Repository}}:{{.Tag}}" | grep "ocrmypdf" | awk -F: '{print $1}')

 

[Stationary]

Mit “docker rmi -f” habe ich sonst immer die Images aus einer Ubuntu VM auf dem Mac gelöscht, die entstanden sind, wenn ich selbst Container gepackt habe, irgendwann war dann nämlich immer die VM voll. Geht also auch hier, sehr gut aber, daß das jetzt automatisiert ist.

 

[peterhoffmann]

Nutzt du die Version 1.2.0?

Ich nutze DSM 6.2.4-25556 Update 4.
Lt. Paketzentrum hat synOCR die Version 1.1.2. Etwas neueres wird nicht angeboten.

Ist die Option zum automatischen Aktualisieren in der GUI gesetzt?

Option "Docker Images aktuell halten"? Wenn ja, dann ja. Es steht auf "aktuell halten".

 

[geimist]

Version 1.2.0 ist aktuell (Link in Signatur).
Ich warte schon über einen Monat (15.1.22) auf Freigabe auf cphub.net

 

[Stationary]

einfach drüber

Bei der 1.2 kommt beim Installieren eine Warnmeldung: "This package does not contain a digital signature." Ist das normal?

 

[mamema]

...bevor wir hier HAARscharf aneinander vorbeireden. Ja, gut, man kann via terminal docker Befehle absetzen, aber ich bezog mich auf Docker Portainer, schaut Euch nochmal meinen Screenshot an:

- ich hatte unused VOLUMES
das ist != unused IMAGES

das wären zwei unterschiedliche Putzaktionen

..und bezüglich den volumes wäre der terminal command: docker volume ls -f dangling=true

.Du, Stephan putzt nur Images

 

[geimist]

Bei der 1.2 kommt beim Installieren eine Warnmeldung: "This package does not contain a digital signature." Ist das normal?

Ja, das ist normal. Über cphub.net geladen, wäre eine digitale Signatur drin (das wurde mit DSM7 aber eh abgeschafft).

bevor wir hier HAARscharf aneinander vorbeireden.

Ja, da haben wir uns missverstanden …
Zu den Volumes kann ich dir aber nichts sagen. Und du bist dir sicher, dass die alle von OCRmyPDF stammen?
Was ist denn in so einem Volume drin?

 

[mamema]

ja war ocrmypdf. kann ich Dir nicht sagen was da drin ist. Das kommt vom image Entwickler. Hier unterscheidet man zwei Arten:

1.) man MUSS volumes auf ein Verzeichnis mappen via Containererstellung (-v /volume1/docker/schubidu:/data/schubidu
oder
2.) wenn 1 nicht gemacht ist, ist der Container so intelligent und erstellt für schubidu ein volume

wird der Container gelöscht, bleibt das volume verwaist zurück (2) oder die Daten bleiben im Verzeichnis /volume1/docker/schubidu (1) zurück

Ich weiss sehr genau, dass die verwaisten Volumes bei mir vom ocrmypdf kamen, denn auf dem System laufen genau zwei Container. Eines ist ocrmypdf und das andere ändert alle halbe Jahre.....

diese volumes schleichen sich oft ein, wenn der Container Ersteller diese für irgendwas anlegt, dem Nutzer aber nicht explizit mitteilt, leg dafür ein -v Mapping auf ein Hostverzeichnis.

Anbei mal ein Screenshot der Volumes und Mappings von Nextcloud OnlyOffice
Man kann den Unterschied gut sehen.
Alle kryptischen Volumes wie z.B. 9bfbdc1b7a9add15dd1a94f50e9ad4d2a6fee4c1fff3f28e4bee4d29a9e28357
sind bei Containererstellung vom Container OHNE mein zutun erstellt worden.