Hide Forgot
Description of Problem: At least with microtek2 backend when using automatic document feeder xsane informs that it does not have anymore a paper in a feeder by popping out an alert with a text, roughly, "Failed to start scanner. I/O error!". Regular users are at least confused. This may actually be an error in sane-backends which seem to have a habit to signal any unusual condition by raising an I/O error. I attach a gross workaround which makes xsane to come out with an informational alert instead which says something like "Scanned (so many) pages" instead. A side effect is that if we will get a real I/O error _after_ some pages from ADF were already scanned then we will get "Scanned ..." as well. In this application this is vastly preferrable state of affairs.
Created attachment 39126 [details] patch to replace i/o error from ADF with "scanned ..." message
From your debugging of this, can you confirm that the microtek2 backend is returning SANE_STATUS_NO_DOCS at this point? (If not it's a backend bug.)
I suggested in my original report that a simpicistic behaviour of a backend (I do not know if this is limited to microtek2 or more widespread) is actually responsible. As I understand that code it just shouts "I/O error" at every unusual situation. Unfortunately I had an access to this scanner for a very limited time (and to another scanner from HP which does not really work either with Linux nor with a manufacturer provided Windows software). A patch I included is just a workaround for a bad behaviour but it makes the whole thing acceptable from a point of view of the end user and I do not see how it really harms anything in this interactive by its nature procedure of scanning. Throwing at user "scanner failed to start" at the end of every scan which was using ADF is not a good thing to do; it still does that, rightly so, in most situations when errors are different that "no more pages to scan". An alternate, correct, fix would be to carefuly review the whole code and ensure that all backends are smarter in their reporting but this is a long range project.
Yes. Well, since neither of us have the hardware to test out any potential fix (rather than work-around), I'm going to close this as WONTFIX for now.
Pity; because a reaction I got from "end users", which are not interested in internals of SANE, to the current state of things was "absolutely unacceptable". No amount of explanations and hand waving was good enough. A long range solution is to pester SANE project to mend their ways but there is a need for a short term resolution _right now_.
I've reported it to the SANE developers. Reassigning to sane-backends, in hopes that the backend maintainer will produce a patch.. I'd rather not just apply the work-around, since it has the side-effect of masking real problems as well.