synOCR synOCR - GUI für OCRmyPDF

[stewol]

Hallo und einen enstpannten Sonntag euch allen.

Ich bin im moment am versuchen mein Zettelcaos in die Digitale Welt zu verbannen und das was ich hier bis jetzt so gelesen habe hört sich echt toll an. Respekt an all die fleisigen.
Ich habe mir synOCR installiert und bekomme es leider nicht hin.
Die pdf`s landen in dem richtigen ordner aber wenn ich sie öffnen will meckert adobe (Diese Datei verlangt Konformität mit dem PDF/A Standart und wurde schreibgeschützt geöffnet um Änderungen zu verhindern).
In den Log dateien sieht es folgendermaßen aus:

-----------------------------------
| ==> Installationsinfo <== |
-----------------------------------

synOCR-User: root
synOCR-Version: 0.15.2
Architektur: x86_64
DSM-Build: 24922
Gerät: 216plus ()
aktuelles Profil: OCR Synology
verwendetes Image: jbarlow83/ocrmypdf
verwendete Parameter: -srd -l deu
ersetze Suchpräfix: yes
Umbenennungssyntax: §y-§m-§d_§tag_§tit
Loglevel: normal
Anwendungsverzeichnis: /usr/syno/synoman/webman/3rdparty/synOCR
Quellverzeichnis: /volume1/Dokumente/1 Neue Scans/1 Neu/
Quellverzeichnis: /volume1/Dokumente/1 Neue Scans/2 Texterkennung/
BackUp-Verzeichnis: /volume1/Dokumente/1 Neue Scans/4 Sicherung Texterkennung/


----------------------------------
| ==> Funktionsaufrufe <== |
----------------------------------

VERARBEITE: --> 20190825_130535_Stewol_0000003034.pdf (Tue Oct 22 00:00:03 CEST 2019)
temp. Zieldatei: /tmp/tmp.5QFYUgHNf3/20190825_130535_Stewol_0000003034.pdf

--> OCRmyPDF-LOG:
INFO - reading file from standard input
INFO - Start processing 2 pages concurrent
WARNING - 2: 2: [tesseract] took too long to OCR - skipping
WARNING - 1: 1: [tesseract] took too long to OCR - skipping
WARNING - 3: 3: [tesseract] took too long to OCR - skipping
WARNING - 4: 4: [tesseract] took too long to OCR - skipping
INFO - Optimize ratio: 1.00 savings: -0.0%
INFO - Image optimization did not improve the file - discarded
INFO - Output sent to stdout
<-- OCRmyPDF-LOG-END

Zieldatei (OK): /volume1/Dokumente/1 Neue Scans/2 Texterkennung/20190825_130535_Stewol_0000003034.pdf
--> übertrage die Dateirechte und -besitzer (verwende ACL)
Datum nicht gefunden - verwende Dateidatum:
Tag: 21
Monat:10
Jahr: 2019
wende Umbenennungssyntax an --> 2019-10-21__20190825_130535_Stewol_0000003034
Zieldatei: 2019-10-21__20190825_130535_Stewol_0000003034.pdf
--> verschiebe Quelldatei nach: /volume1/Dokumente/1 Neue Scans/4 Sicherung Texterkennung/20190825_130535_Stewol_0000003034.pdf
INFO: (PushBullet-TOKEN nicht gesetzt)
INFO: (Laufzeit letzte Datei: 3638 Sekunden (Seitenanzahl: 4) | gesamt: 8 PDFs / > 20 Seiten bisher verarbeitet)


vllt kann mir ja jemand helfen.

ach so ich habe eine DS216+
und mir ist aufgefallen das kaum Systemresoucen benutzt werden es dauert einfach nur ewig (was mich aber nicht stört läuft ja eh immer) hat mich halt nur gewundert das es so lange dauert und nur 5% cpu benutzt.


MfG Stefan

 

[geimist]

Herzlich willkommen hier im Forum

Ich verstehe noch nicht dein Hauptproblem. Die Meldung von Adobe ist ja kein Fehler. ocrmypdf speichert standardmäßig in PDF/A (was für die Langzeitarchivierung konzipiert ist). Dennoch kann man entsprechende Dateien in Adobe bearbeiten - man muss sie dann lediglich als Kopie speichern.

OCRmyPDF ist sehr ressourcenintensiv, aber auch mehrseitige Dokumente sind in der Regel in wenigen Minuten abgearbeitet. Daher wundert mich dein Log schon etwas. OCRmyPDF gibt ja auch eine Fehlermeldung aus.

Wie sieht es mit anderen Dokumenten aus?
Kannst du mal eine andere Containerversion (z.B. alpine) testen?

 

[stewol]

Danke für die schnelle antwort.
Ja habe ganz vergessen zu schreiben das adobe zwar mecker aber es ist leider kein ocr vorhanden.
Ich habe mehrere Dokumente durchlaufen lassen und es kommt zu 90% der teil mit dem "WARNING - 1: 1: [tesseract] took too long to OCR - skipping"
Nur bei einem Dokument hat es mal funktioniert. Mich wundert halt das (ich vermute mal das ist eine art timer der sagt das es zu lange dauert) abläuft und kaum resoucen genutzt werden.
Ich habe aber leider nicht so viel ahnung von dem ganzen....
Was ist mit anderer containerversion gemeint also anstatt ocrmypdf alpine im docker installieren?

 

[geimist]

Ziemlich sicher hat OCRmyPDF selbst ein Problem mit deinen PDFs. Dabei kann ich dir nicht wirklich weiterhelfen.

Daher:

… Was ist mit anderer containerversion gemeint also anstatt ocrmypdf alpine im docker installieren?

Unter synOCR -> Konfiguration -> "OCR Optionen und Umbenennung" kannst du verschiedene Versionen von OCRmyPDF auswählen. Dort mal bitte einen anderen Container testen.

 

[stewol]

Unter synOCR -> Konfiguration -> "OCR Optionen und Umbenennung" kannst du verschiedene Versionen von OCRmyPDF auswählen. Dort mal bitte einen anderen Container testen.

Ich habe das mal umgestellt und getestet leider ohne erfolg
-----------------------------------
| ==> Installationsinfo <== |
-----------------------------------

synOCR-User: root
synOCR-Version: 0.15.2
Architektur: x86_64
DSM-Build: 24922
Gerät: 216plus ()
aktuelles Profil: OCR Synology
verwendetes Image: jbarlow83/ocrmypdf-alpine
verwendete Parameter: -srd -l deu
ersetze Suchpräfix: yes
Umbenennungssyntax: §y-§m-§d_§tag_§tit
Loglevel: normal
Anwendungsverzeichnis: /usr/syno/synoman/webman/3rdparty/synOCR
Quellverzeichnis: /volume1/Dokumente Stefan/1 Neue Scans/1 Neu/
Quellverzeichnis: /volume1/Dokumente Stefan/1 Neue Scans/2 Texterkennung/
BackUp-Verzeichnis: /volume1/Dokumente Stefan/1 Neue Scans/4 Sicherung Texterkennung/


----------------------------------
| ==> Funktionsaufrufe <== |
----------------------------------

VERARBEITE: --> 20190908_123243_Stewol_0000003070.pdf (Sun Oct 27 12:33:55 CET 2019)
temp. Zieldatei: /tmp/tmp.3KyOyweicp/20190908_123243_Stewol_0000003070.pdf

--> OCRmyPDF-LOG:
Unable to find image 'jbarlow83/ocrmypdf-alpine:latest' locally
latest: Pulling from jbarlow83/ocrmypdf-alpine
e7c96db7181b: Pulling fs layer
9d9d86b2306e: Pulling fs layer
626f2b04c8c7: Pulling fs layer
8cb86e060c67: Pulling fs layer
8cb86e060c67: Waiting
70dca71c2e35: Pulling fs layer
4c216d68e50a: Pulling fs layer
70dca71c2e35: Waiting
90d0fc40a8fd: Pulling fs layer
4c216d68e50a: Waiting
f4f9f0827e45: Pulling fs layer
5081b86884a3: Pulling fs layer
90d0fc40a8fd: Waiting
f4f9f0827e45: Waiting
5081b86884a3: Waiting
e7c96db7181b: Verifying Checksum
e7c96db7181b: Download complete
8cb86e060c67: Verifying Checksum
8cb86e060c67: Download complete
70dca71c2e35: Verifying Checksum
70dca71c2e35: Download complete
4c216d68e50a: Download complete
626f2b04c8c7: Verifying Checksum
626f2b04c8c7: Download complete
90d0fc40a8fd: Verifying Checksum
90d0fc40a8fd: Download complete
5081b86884a3: Verifying Checksum
5081b86884a3: Download complete
f4f9f0827e45: Verifying Checksum
f4f9f0827e45: Download complete
e7c96db7181b: Pull complete
9d9d86b2306e: Verifying Checksum
9d9d86b2306e: Download complete
9d9d86b2306e: Pull complete
626f2b04c8c7: Pull complete
8cb86e060c67: Pull complete
70dca71c2e35: Pull complete
4c216d68e50a: Pull complete
90d0fc40a8fd: Pull complete
f4f9f0827e45: Pull complete
5081b86884a3: Pull complete
Digest: sha256:
Status: Downloaded newer image for jbarlow83/ocrmypdf-alpine:latest
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/pikepdf/__init__.py", line 10, in <module>
from . import _qpdf
ImportError: Error loading shared library libqpdf.so.26: No such file or directory (needed by /usr/lib/python3.6/site-packages/pikepdf/_qpdf.cpython-36m-x86_64-linux-gnu.so)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/bin/ocrmypdf", line 5, in <module>
from ocrmypdf.__main__ import run
File "/usr/lib/python3.6/site-packages/ocrmypdf/__init__.py", line 18, in <module>
from . import helpers, hocrtransform, leptonica, pdfa, pdfinfo
File "/usr/lib/python3.6/site-packages/ocrmypdf/pdfa.py", line 40, in <module>
import pikepdf
File "/usr/lib/python3.6/site-packages/pikepdf/__init__.py", line 12, in <module>
raise ImportError("pikepdf's extension library failed to import")
ImportError: pikepdf's extension library failed to import
read unix @->/var/run/docker.sock: read: connection reset by peer
<-- OCRmyPDF-LOG-END

L=> fehlgeschlagen! (Zieldatei ist leer oder nicht vorhanden)


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

habe noch eine ander pdf datei probiert aber auch hier kein erfolg.

-----------------------------------
| ==> Installationsinfo <== |
-----------------------------------

synOCR-User: root
synOCR-Version: 0.15.2
Architektur: x86_64
DSM-Build: 24922
Gerät: 216plus ()
aktuelles Profil: OCR Synology
verwendetes Image: jbarlow83/ocrmypdf-alpine
verwendete Parameter: -srd -l deu
ersetze Suchpräfix: yes
Umbenennungssyntax: §y-§m-§d_§tag_§tit
Loglevel: normal
Anwendungsverzeichnis: /usr/syno/synoman/webman/3rdparty/synOCR
Quellverzeichnis: /volume1/Dokumente Stefan/1 Neue Scans/1 Neu/
Quellverzeichnis: /volume1/Dokumente Stefan/1 Neue Scans/2 Texterkennung/
BackUp-Verzeichnis: /volume1/Dokumente Stefan/1 Neue Scans/4 Sicherung Texterkennung/


----------------------------------
| ==> Funktionsaufrufe <== |
----------------------------------

VERARBEITE: --> 20190825_130438_Stewol_0000003032.pdf (Sun Oct 27 12:56:11 CET 2019)
temp. Zieldatei: /tmp/tmp.OpWhfsIkkV/20190825_130438_Stewol_0000003032.pdf

--> OCRmyPDF-LOG:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/pikepdf/__init__.py", line 10, in <module>
from . import _qpdf
ImportError: Error loading shared library libqpdf.so.26: No such file or directory (needed by /usr/lib/python3.6/site-packages/pikepdf/_qpdf.cpython-36m-x86_64-linux-gnu.so)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/bin/ocrmypdf", line 5, in <module>
from ocrmypdf.__main__ import run
File "/usr/lib/python3.6/site-packages/ocrmypdf/__init__.py", line 18, in <module>
from . import helpers, hocrtransform, leptonica, pdfa, pdfinfo
File "/usr/lib/python3.6/site-packages/ocrmypdf/pdfa.py", line 40, in <module>
import pikepdf
File "/usr/lib/python3.6/site-packages/pikepdf/__init__.py", line 12, in <module>
raise ImportError("pikepdf's extension library failed to import")
ImportError: pikepdf's extension library failed to import
time="2019-10-27T12:56:43+01:00" level=error msg="error waiting for container: context canceled"
read unix @->/var/run/docker.sock: read: connection reset by peer
<-- OCRmyPDF-LOG-END

L=> fehlgeschlagen! (Zieldatei ist leer oder nicht vorhanden)


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

Gibt es hier im Forum eigentlich eine Funktion um so Log Texte zu verbergen damit meine Posts nicht so riesig werden?

 

[geimist]

Hier ist ja wieder ein anderes Problem im entsprechenden Image. Probiere bitte einfach mal durch (auch mal das ältere v.8.2.3). Eigentlich sind so viele Probleme unüblich …

… Gibt es hier im Forum eigentlich eine Funktion um so Log Texte zu verbergen damit meine Posts nicht so riesig werden?

Beim Erstellen des Posts unten auf "Erweitert" neben "Antworten" klicken. In dieser Ansicht gibt es auch ein Code-Tag (#).

 

[jxsl13]

Moin,
wie schwierig ist eine Ergänzung dahingehend, dass man aus dem OCR'ten Dokument dann das richtige Datum, das im Dokument vorkommt, matcht, am liebsten via Regex(manuell für Enthusiasten) und mit vorgegebenem Regex für Normalsterbliche, und im Dokumentennamen verwurstet, sodass man das Dokument chronologisch einsortieren kann.

Am liebsten wäre natürlich, dass die Überschrift des Dokumentes erkannt würde, aber ich weiß nicht so recht, inwiefern Schriftgröße o.ä. Informationen im ocr'ten Text enthalten sind, wahrscheinlich gar keine.

 

[geimist]

Das sollte es doch tun …
Für den Suchbereich (1. Seite oder komplettes Dokument [Suchbereich tags]) gibt es einen eigenen Schalter.
Allerdings gibt es hin und wieder false postive Ergebnisse (die ich in meiner Laienhaftigkeit noch nicht nachvollziehen konnte). Es wird nach 3 Formatierungen gesucht (findest du hier ab Zeile 414).

Wird kein Datum gefunden, so wird das Dokumentdatum verwendet.

 

[jxsl13]

Also wird das ocr'te Datum in der Eingabemaske konfiguriert(Umbenennen des Dokumentes) und nicht das aktuelle Oo? Kam mir irgendwie nicht so vor beim lesen der Tooltips :/

Ich frage mich, ob etwas gegen die Nutzung von Python3 anstatt von Shellskripten spricht ?

In dem Regex in Zeile 414 scheint mir der Fall zu fehlen, wo ein Datum mit einer führenden 0 beginnt.

founddate=$( parseRegex "$content" "([1-9]|[1-2][0-9]|3[0-1])[\./-][0-1]?[0-9][\./-](19[0-9]{2}|20[0-9]{2}|[0-9]{2})" | head -n1 )

Hätte man etwas der Form 99.12.2019, würde der Regex scheinbar auch matchen.
Naja, eine Kleinigkeit, die trotzdem bei einer nicht vorhandenen führenden 0 trotzdem komisch abzufangen wäre.

Ich finde es etwas schade, dass die Repo nicht auf GitHub gehostet wird, da man sich erst einmal über Umwege einen Account anlegen muss, anstatt ggf einfach eine Issue aufzumachen oder direkt einen PR.

 

[geimist]

Im Tooltip steht:

… Datumsangaben werden zuerst im Dokument gesucht. Wenn erfolglos, wird das Dateidatum verwendet

Sollte ich das besser formulieren?

… Ich frage mich, ob etwas gegen die Nutzung von Python3 anstatt von Shellskripten spricht ? …

• meine Fähigkeiten (hab noch nie etwas mit Python gemacht)
• sofern möglich, möchte ich vermeiden, dass von Usern weitere Pakete installiert werden müssen. Das ist aber nicht in Stein gemeiselt.

… Ich finde es etwas schade, dass die Repo nicht auf GitHub gehostet wird, da man sich erst einmal über Umwege einen Account anlegen muss, anstatt ggf einfach eine Issue aufzumachen oder direkt einen PR.

Ich finde das eigentlich ganz nett mit Gitea
Ich erstelle dir gern einen Account und freue mich auch immer über Unterstützung. Schick mir einfach deine Mailadresse per PN oder an synocr ät geimist.eu

RegEx:
Ein Beispiel für ein false positiv match :

                          prüfe Datum: 049/011-2/017-110-110-020/7 --> gültig
                          Tag:  02
                          Monat:11
                          Jahr: 049

 

[jxsl13]

Der aktuelle Regex:
https://regex101.com/r/zNkC9C/3

Mit einem kleinen fix der Regex:
https://regex101.com/r/zNkC9C/4


Python bietet von Haus aus schon eine mächtige Bibliothek mit, die einem solches hier ggf. erspart
Man siehe z.B.
https://stackoverflow.com/questions/45080248/how-to-extract-date-from-string-using-python-3-x

 

[geimist]

Danke schonmal

 

[jxsl13]

Hier ein Beispiel-Python-Script, das ohne zusätzliche Dependencies(sprich packages/libraries) auch deinen Fall abdeckt:

import dateutil.parser as dparser

date = None

lines = [
    "049/011-2/017-110-110-020/7", 
    "99.5.2019", 
    "9.5.2019", 
    "12.09.1998", 
    "31.02.1995",
    "12 Sep 2019"
    ]

for txt in lines:
    try:
        date = dparser.parse(txt,fuzzy=True)
    except ValueError:
        print("Unknown format", txt)
    else:
        print(date)

Ausgabe:

Unknown format 049/011-2/017-110-110-020/7
Unknown format 99.5.2019
2019-09-05 00:00:00
1998-12-09 00:00:00
Unknown format 31.02.1995
2019-09-12 00:00:00

Zudem werden deutlich mehr Datumsformate erkannt und das ggf. mit weniger Aufwand.

 

[jxsl13]

Habe die Beschreibung gar nicht gesehen von den Datumsvariablen, weil dort so viel steht, dass ich erst heruntersollen musste :O

Zudem, wenn man in der Eingabemaske bei den Ordnern kein abschließendes "/" angibt, wird das Verzeichnis nicht gefunden.
Ich weiß gerade nicht, wie der default Wert war, ob dort ein abschließendes "/" stand. Kleinigkeiten, die die User Experience verbessern.


Eine weitere Funktion, die sehr hilfreich wäre, wäre dass z.B. das Dokumentendatum >= eines Custom Datums sein sollte oder z.B. durch Dropdown-Menü o.ä. auf maximal 7 Tage, 1 Monat, 3 Monate, 6 Monate, 1 Jahr, 2 Jahre, 5, Jahre, 10 Jahre alt sein kann.
Manche Dokumente beinhalten z.B. das Geburtsdatum(z.B. Lohnsteuerabrechnungen), das dann fälschlicherweise erkannt wird.

 

[stewol]

Hi ich bins nochmal

Hier ist ja wieder ein anderes Problem im entsprechenden Image. Probiere bitte einfach mal durch (auch mal das ältere v.8.2.3). Eigentlich sind so viele Probleme unüblich …

Leider alle durchprobiert ohne Erfolg. Naja soll bei mir wohl nicht klappen

Trotzdem Vielen Dank für die Hilfe vllt liegt es einfach an meinen PDF's das die nicht von ocrmypdf verarbeitet werden können.

LG Stefan

 

[geimist]

… wenn man in der Eingabemaske bei den Ordnern kein abschließendes "/" angibt, wird das Verzeichnis nicht gefunden. …

Das wird standardmäßig gecheckt - alle Ordner sind in meiner Konfig ohne abschließenden Slash

… Leider alle durchprobiert ohne Erfolg. Naja soll bei mir wohl nicht klappen …

Das tut mir wirklich leid
Sind das frisch gescannte PDFs, oder stammen die aus einer anderen Quelle? Du siehst ja im Thread, dass es kein grundlegendes Problem diesbezüglich gibt.
Ich würde dir gerne helfen …

 

[peterhoffmann]

vllt liegt es einfach an meinen PDF's das die nicht von ocrmypdf verarbeitet werden können.

Probiere es doch erst mal mit anderen PDFs (aus mehreren anderen Quellen) um zu sehen, ob es an deinen PDFs oder am System liegt.

 

[stewol]

Ja gute Idee das werde ich machen habe da aber im moment keine Zeit für habe in einer Woche Prüfungen danach werde ich es nochmal versuchen

 

[geimist]

Hier ein Beispiel-Python-Script, das ohne zusätzliche Dependencies(sprich packages/libraries) auch deinen Fall abdeckt:
…
Zudem werden deutlich mehr Datumsformate erkannt und das ggf. mit weniger Aufwand.

Das ist bestimmt eine schöne Sache. Ich könnte mir gut vorstellen, dass man auf das Pythonscript für die Datumssuche zurückgreift. Dafür muss vom User das Paket "Python Module" installiert werden. Als Fallback gäbe es dann die bisherige Variante. Allerdings funktionierten meine ersten Versuche nicht zufriedenstellend.
Z.B.

• wurde ein deutsches Datum amerikanisch interpretiert (Tag und Monat vertauscht) - (setlocale) half nicht
• des Weiteren wäre es schön, wenn man auch gleich ausgeschriebene Monate parsen könnte.
• Zeilen mit Umlaut führten zum Abbruch - (setlocale) half nicht

Es gibt wohl noch eine Funktion dateparser, die ich aber auf der DS nicht finden konnte (und pip scheint auch nicht out of the box zu funktionieren).

#!/bin/python

import locale
locale.setlocale(locale.LC_ALL, 'de_DE.utf8')

lines = [
    "das Datum 17. Oktober 2019 mit ausgeschriebenen Monat", 
    "das Datum 9.5.2019 wird amerikanisch interpretiert (scheint immer dann der Fall zu sein, wenn die fuehrende Null fehlt)", 
    "das Datum 9.7.2015 wird nicht erkannt (scheint immer dann der Fall zu sein, wenn noch weitere Zahlen in der Zeile vorkommen 0 )", 
    "12.9.1998", 
    "12. Sep. 2019"
    ]

import dateutil.parser as dparser

date = None

#with open('/volume1/DEV/datetest.txt', 'r') as lines:
for txt in lines:
    try:
        date = dparser.parse(txt,fuzzy=True)
    except ValueError:
        print("Unknown format", txt)
    else:
        print(date)

admin@DS:~$ /volume1/DEV/test.py
('Unknown format', 'das Datum 17. Oktober 2019 mit ausgeschriebenen Monat')
2019-09-05 00:00:00
('Unknown format', 'das Datum 9.7.2015 wird nicht erkannt (scheint immer dann der Fall zu sein, wenn noch weitere Zahlen in der Zeile vorkommen 0 )')
1998-12-09 00:00:00
2019-09-12 00:00:00

 

[Televisor]

Umsetzungsvorschlag Batch-Scannen mit Trennblättern

Das entspricht ja dem Vorschlag von koen.
Eine Umsetzung wird aber nicht heut und morgen, da ich auch erst einmal sehen muss, mit welcher Software ich das umsetzen kann (wenn jemand einen Tipp hat - immer her damit ). Das nächste größere, was ich umsetzen möchte, sind Profile. Dazu muss ich aber von der Konfigurationsdatei auf eine Datenbank umstellen, was wiederum zusätzlichen Aufwand bedeutet.

Hallo Stephan,

Bezüglich Batch-Scannen mit Trennblättern bin ich auf die OpenSource-Lösung www.naps2.com gestossen. Ist ein Windows-Programm, lässt sich aber portable nutzen und vor allem scriptbasiert in der Konsole aufrufen! Auch der Wunsch des Users koen lässt sich damit umsetzen, da das Auftrennen des Batchstapels beim Scanaufruf erfolgt und die einzelnen PDF's dann im Input-Ordner landen. Naps2 kann könnte auch OCR, lasse ich aber deaktiviert. Gemäss Naps2-Doku kann das alles auch unter Linux via Mono laufen und Mono - glaube ich - gibt es doch auch via Docker? Vielleicht hilft mein Input für einen schlauen Lösungsansatz, dies im Workflow zu integrieren? Auf jeden Fall ist der bisherige Stand schon ein hervorragendes Tool und ich danke bereits allen Beteiligten für diese tolle Arbeit!

Grüsse, Televisor