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.