Naja, deswegen schrieb ich ja im Titel “Import von Scans”!
Die werden per ScanSnap gescannt, und dann über den Importordner in DT3 eingefügt.
Funktionierte sehr lange prima, aber leider seit heute nicht mehr…
Sorry, aber 12.3.1 wird zumindest mir hier in Deutschland bisher nicht angeboten. Kommt vielleicht noch im laufe des Abends?
Ich sehe hier aber ehrlich gesagt keinen Zusammenhang!
Wieso sollte es plötzlich nicht mehr funktionieren, nachdem es das lange gut gemacht hatte, nur weil macOS geupdated wird, DT3 aber eben nicht geupdated wurde?
Ich würde dies verstehen, wenn es für DT3 ein Update gab, aber das ist hier noch auf 3.8.3, wenn also beide Softwareversionen nicht geändert wurden, es bisher gut funktioniert hat, und vor allem, nach allem was man im Internet zu 12.3.1 finden kann, dieses Update auch zumindest offensichtlich nichts (es geht hier weder um Bluetooth, noch um einen per USB-C angeschlossenen zweiten Monitor an einem Mac mini (2018)) mit dem hiesigen Problem zu tun haben soll, erschließt sich mir nicht, warum das Problem verschwinden sollte, wenn das Update durchgeführt wurde?
Normalerweise ist es genau anders herum…
Ach ja, und ich gehöre verrückterweise zu denjenigen, die ein Update immer innerhalb weniger Stunden nach der Veröffentlichung einspielen.
Der Hinweis, ich sollte mein System up to date halten, ist daher irgendwie unnötig…
Zum einen, weil man sich über das Betriebssystem und unsere Neuerscheinungen auf dem Laufenden halten sollte, was viele nicht tun.
Zum anderen erzwingen Updates auch einen Neustart des Rechners. Das ist etwas anderes, was die Leute oft vernachlässigen: einen Rechner gelegentlich neu zu starten.
Ein Neustart ist nicht nur eine faule Support-Antwort. Er beseitigt oder lindert oft Probleme auf einem Gerät.
Was ist in den Einstellungen Ihres ScanSnap-Profils festgelegt? Ein Bildschirmfoto könnte hilfreich sein.
Ich habe den Neustart alle drei Tage in meiner GTD-Taskliste drinnen.
Und natürlich, vor dem eröffnen des Tickets, extra einen gemacht, um diese Probleme abzufangen.
Ich mache das auch nicht erst seit gestern.
Auch ein nun durchgeführtes Update auf 12.3.1 hat, wie zu erwarten, nichts gebracht. Das Problem dass die eingehenden Scans, anders als in den letzten Tagen, nicht mehr mit OCR behandelt werden, ist unverändert vorhanden.
Das ScanSnap-Profil sieht hierfür so aus:
Die Hazel-Rule, die den Scan dann in den Eingang von DT3 verschiebt, sieht so aus:
Kurz bevor ich das Problem das erste Mal festgestellt habe, habe ich die folgende Regel angelegt:
Das Problem ist aber vorhanden, unabhängig davon, ob die Regel aktiviert ist, oder nicht.
Eine automatische OCR wird m.W. nur auf direkt von der Scannersoftware an DT übermittelte Dateien angewandt. Dein Vorgehen, nämlich die PDF über einen Ordner mittels Hazel an DT, dürfte den Mechanismus nicht auslösen. Hast du bisher mittels einer intelligenten Regel (z.B. Art ist PDF, Wortzahl ist 0) OCR ausgelöst? Wenn ja, poste bitte die Regel; in welcher Position ist sie in der Regelabfolge?
Warum schickst du die Scans nicht direkt aus SnapScan an DT?
Ich glaube ich schrieb es schon mal, ich arbeite mit dieser Regel seit einigen Tagen. Bates Nummer wird nicht immer eingefügt - #9 by Ulli
Seitdem habe ich geschätzt über 100 Scans so durchgeführt, und die wurden alle beim Eingang mit OCR versehen, und dann in DT3 weiterverarbeitet. Völlig problemlos, bis ich heute leider feststellen musste, dass es nun plötzlich nicht mehr geht.
Und ich gehe diesen Weg, um die Datei mit einem Tag versehen zu können, wie man auf dem Screenshot der Hazelrule sehen kann.
Damit kann ich dann in DT3 automatisch die Bates-Stempelung auslösen, ohne (bisher) über Probleme mit “nicht eindeutigen” Dateinamen o.ä. zu stolpern.
Ich habe jetzt in DT3 eine neue Regel erstellt, um das OCR auszulösen, wenn ein PDF importiert wird, welches “0 Buchstaben” enthält.
Diese Regel funktioniert jetzt auch mit meinem Dokument.
Leider löst diese Regel aber nicht den Trigger “nach OCR” in einer anderen Regel aus.
Wenn ich das OCR in DT3 manuell ausführe, also ohne Regel, dann löst die Regel, die den Trigger “nach OCR” hat, zuverlässig aus.
Wie ist dies zu erklären?
Korrekt, per se lösen Regeln keine anderen Regeln aus; damit sollen Regelschleifen vermieden werden. Eine Regel kann eine ausgewählte Folgeregel auslösen.
Interessant, das ist nicht das Verhalten, das ich erwartet hätte.
Das ist korrekt.
Wenn tatsächlich DT3 keinen automatisches OCR durchführt, nachdem ein PDF ohne OCR über die Inbox hinzugefügt wurde, dann stellen sich hieraus für mich zwei Fragen:
- Warum hat DT3 das dann bei mir über eine Woche bis gestern trotzdem gemacht?
- Warum macht DT3 überhaupt einen Unterschied darin, woher ein PDF ohne OCR kommt!? Die OCR-Schicht ist die wesentliche Voraussetzung dafür, dass ein PDF in DT3 überhaupt sinnvoll verarbeitet werden kann. Ohne OCR ist ein PDF in DT3 nur eine x-beliebige Datei, mit OCR kann DT3 mit der Datei erst arbeiten, sie sinnvoll suchen etc. Wenn also hier ein Unterschied gemacht wird, dann wäre es aus meiner Sicht als Nutzer sinnvoll, diesen Unterschied abzuschaffen, da es für mich als User im Grunde keinen Unterschied machen sollte, ob ich ein PDF direkt vom Scanner an DT3 senden lasse, hierfür den Sorter nutze, oder die Inbox im Finder.
Dies sollte dann meines Erachtens in Zukunft so angepasst werden, dass jedes PDF ohne OCR von DT3 erstmal mit einem OCR versehen werden kann. (Und für die, die das nicht mögen, man kann sowas ja, wie bisher auch, abschaltbar gestalten!)
Ich glaube wir reden hier aneinander vorbei.
Wenn ich eine Regel A habe, die ein OCR durchführt. Und eine Regel B habe, die sich triggern soll, wenn ein OCR durchgeführt wurde (“Nach OCR”), dann erwarte ich als Nutzer, dass genau dies auch geschieht.
Es muss für Regel B völlig egal sein, was das OCR ausgelöst hat, und ich kann in der Dokumentation dazu auch keinen Hinweis finden, dass es tatsächlich nicht egal wäre.
Hier kann auch keine “Regelschleife” entstehen, da Regel A verständlicherweise nicht getriggert werden kann, wenn Regel B durchgelaufen ist, da die Datei dann ja ihre OCR-Schicht bereits hat.
Regelschleifen entstehen dadurch, dass die Eingangsregel einer Regel A, der Ausgangskondition einer Regel B entspricht.
Ein einfaches Beispiel ist meine Regel, die ich geschrieben habe, um ein Tag zu einer Datei hinzuzufügen. Hier war es notwendig, dass die Regel erst einmal prüft, ob das Tag nicht schon vorhanden ist, bevor es das Tag setzt. Ohne diese Eingangsprüfung würde diese Regel tatsächlich in einer Schleife laufen, aber auch hier unabhängig von anderen Regeln.
Das stimmt in dieser Absolutheit nicht. Es gibt z.B. handgeschriebene Rechnungen auf Papier. Wenn ich die scanne, bekomme ich ein PDF. Auf dem allerdings OCR zu betreiben, ist reichlich sinnfrei. Trotzdem ist das ein Dokument für meine Buchhaltung, und ich kann Herkunft, Datum, Zweck und Betrag ohne Schwierigkeiten in Metadaten unterbringen. Auch danach kann ich sinnvoll suchen. Ähnlich sieht es übrigens mit vielen Belegen auf Thermopaier aus: Man muss die sofort kopieren (aka scannen), aber der Scan lässt sich häufig nicht mit OCR brauchbar behandeln.
Nicht jeder bekommt PDFs, die nur aus gedrucktem Text bestehen.
1 Like
Kannste erwarten, tut‘s aber nicht, weil Regeln keine Regeln auslösen. Du kannst aus einer Regel heraus eine weitere ausgewählte Regel auslösen; mit einem Skript kannst du auch alle Regeln nochmal auslösen, wobei das erst ab 3.8.4 (wieder) funktionieren wird. Dass dabei keine Schleifen entstehen muss der Nutzer selbst prüfen, wenngleich bestimmte Schutzmechanismen eingebaut sind/sein werden.
Toll, Du hast Ausnahmen zu meiner allgemein formulierten Feststellung gefunden!
Herzlichen Glückwunsch!!
Dennoch kannst Du mit den von Dir genannten Dokumenten in DT3 eben nicht viel mehr anfangen, als sie nur zu speichern. Dafür benötigt man DT3 aber nicht, das macht der Finder im Zweifel genauso, zumal Du sie, wenn Du damit tatsächlich Buchhaltung betreiben willst, ohnehin in spezielleren Programmen speichern müsstest, da DT3 immer noch nicht den gesetzlichen Anforderungen hierfür entspricht.
Es geht doch hier gar nicht darum, dass eine Regel eine andere auslösen soll, wobei aber eben genau dies doch ausdrücklich möglich ist, wenn ich die zweite Regel in die erste reinschreibe!
Es geht darum, dass die zweite Regel nicht auslöst, weil das OCR von einer Regel angestoßen wurde!
Und das ist ein Fehler, der nicht sein kann!!
Es muss der zweiten Regel völlig egal sein, was das OCR ausgelöst hat. Wenn hier eine versteckte Sperre eingebaut ist, die verhindert dass eine Regel den Trigger “nach OCR” auslöst, nur weil dieser vorher ebenfalls von einer Regel ausgelöst wurde, dann ist dies nicht nur ein erheblicher Fehler in der Programmierung, sondern müsste auch entsprechend dokumentiert sein. Dies ist es aber nicht, bzw. ich habe dies bisher nicht gefunden.
Dann müssten aber auch alle anderen, vermutlich dann bestehenden, versteckten Regelfunktionen etc. irgendwo dokumentiert sein.
Wo steht das alles!?
Du, ich nenne dir bloß die Tatsachen. Die Aktionen einer Regel lösen keine weitere Regel aus.
Ganz grundsätzlich: ich bin hier um zu helfen, nicht um zu streiten. Ich biete anderen hier meine Freizeit an; ich glaube daran, dass wenn jeder Input in eine Community bringt, am Ende auch jeder was davon hat. Heißt: ich weiß viel über DT, lerne aber auch hier durch Interaktion mit anderen viel dazu. Ich habe bislang aber nicht das Gefühl gehabt, dass ich dir in unseren Interaktionen helfen konnte; ich selbst habe sie vielmehr als frustrierend wahrgenommen. Selbst mitnehmen konnte ich nichts. In diesem Sinne wünsche ich dir, dass du im Laufe der Zeit deine Zufriedenheit mit DT steigern kannst, oder aber Software findest, die deinen Vorstellungen entspricht.
1 Like
Ich bin bei DT3 mittlerweile an dem Punkt angekommen, an dem ich vor rund 13 Jahren mit Windows war, und was dazu geführt hat, dass ich damals komplett auf Apple umgestiegen bin.
Ein produktives Arbeiten ist mit DT3 nicht möglich. Vieles was offenbar, entgegen jeder Logik, oder auch den Werbeversprechen der Entwickler, nicht funktioniert, wird einfach als Feature definiert, obwohl es nur Bugs sind.
Bei praktisch jeder Eingabe hängt sich DT3 erstmal auf, teilweise “nur” 2-3 Minuten, teilweise mit dem Zwang zum Neustart.
Die vielbeschworene KI kommt mit meinen Dokumenten überhaupt nicht klar (klar, kann an der Besonderheit meiner Dokumente liegen), und ist daher ebenfalls für mich bestenfalls nutzlos, schlimmstenfalls führt sie dazu, dass ich Tagelang mein Zeug hier neu sortieren muss.
Und dann, wenn man hier im Forum auf die Probleme hinweisen will, kommen immer die gleiche 2-3 verdächtigen, die hier Jubelsstürme ausführen, alles Bugs zum Feature deklarieren, und einem darüber hinaus irgendwelche Skripte ans Herz legen wollen, mit denen das alles ganz toll funktioniert!
Wenn ich Skripten könnte, oder wollte(!), dann bräuchte ich kein teures Programm wie DT3, um meine Dokumente zu verwalten, dann könnte ich das mit den Apple-Hausmitteln auch so lösen!
Wer also zu meinen Beiträgen nichts konstruktives zur Lösungsfindung beizutragen hat, sondern nur mitteilen möchte, warum etwas nicht funktioniert, der darf bei meinen Beiträgen sehr gerne darauf verzichten, das spart mir auch die Zeit, immer wieder darauf eingehen zu müssen…!
Aber eben offensichtlich nicht die ganze Wahrheit!
Nach einiger Recherche und Tüftelei habe ich die Ordneraktion “Devonthink - Import, OCR & Delete” gefunden, der genau das was ich hier benötige, mit jedem beliebigen Ordner ausführen kann.
Ein entsprechender Hinweis hierauf hätte nicht nur eine unnötige Diskussion hier vermieden, sondern mir gestern auch einen Tag Recherche gespart…!
Warum die Inbox von DT3 dies nicht bereits automatisch eingestellt hat, oder man es zumindest irgendwo in den Einstellungen vornehmen kann, ist mir unverständlich, aber offenbar auch hier eine Folge davon, dass offenbar vieles nicht bis zum Ende gedacht wird…
Meine Inbox kann den “Trick” jetzt, geht problemlos das einzustellen, wenn man es weiß!
