DT3.0.1 OCR fails on document that is moved / renamed

(1) Create a batch of documents that are queued up for OCR
(2) While OCR is running, rename one of the documents
(i) A document in the middle of the OCR munching process
(ii) …or a document in the queue waiting to be munched on
(3) Watch the failure happen – definitely with case (ii) but maybe also with case (i)


Why would you rename a document that’s queued up for OCR?

If you anticipate making these modifications, it would be best to do them before OCR or to do OCR one at a time.

1 Like

Hi… I scan lots of docs. I typically rename them at some point, to names that make sense for me for my filing scheme. I also like to OCR everything to improve search ability. Sometimes, I forget the do the operations in a certain order, and sometimes I’ve also queued up a lot of documents – a dozen or more – and don’t want to wait to start renaming them. So I start renaming them anyway. I was surprised when there were subsequent failures… I guess the OS weenie that once lived within me assumed that there was an internal representation that would be queued up, some identifier that would be independent of the user-visible name. So the user-visible name could change even while an operating was in progress… changes could include rename but also relocation to another folder. So much for that assumption on my part. :slight_smile:

I don’t think I saw this problem on DT2 or maybe it was prior to my switch from the Fujitsu ScanSnap scanner to an Epson scanner. The FJ ScanSnap had such a nice level of integration that OCR would happen automatically as I scanned in the docs. But I’ve never achieved such happiness with the Epson scanner; instead, I wind up having to trigger OCR manually, thus creating this window of time where I am tempted to rename / refile the scanned item.

Not the end of the world, this problem, but my OS background makes me expect that I shouldn’t be able to shoot myself in the foot using the provided tools; I would have expected that if an operation would result in failure (like rename or refile) during OCR then the operation would be prohibited during that window.

Anyway, that’s all that I have to contribute on the subject and it’s not like the behavior is something I can’t live with. My love for DT outweighs any of the bugs I’ve reported, by a long shot. :slight_smile: If this bug gets closed out without a fix, so be it.

Thanks for listening!


The OCR engine is same manufacturer but a very upgraded engine, so the comparison with DT2’s operation isn’t totally reliable.

I can’t speak for what can or can’t be done, but Development would have to assess if this is even feasible with the new engine. Perhaps it is, perhaps it isn’t, but I’ll leave it to the person integrating it :slight_smile:

ABBY, yes?

This particular interaction issue is probably not a big deal for most (all?) DT customers, so although I think it’s a reasonable bug report all the way back to whatever engineers have this area of responsibility, I wouldn’t be shocked to see it ranked low for priority to deal with it.


Yes, ABBYY but (for those who may not know) it’s the developer’s version, which isn’t necessarily the same as the consumer version.