New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Brother MFC-L2710DW ADF issue #39
Comments
Hi! Thank you for a lot of information you've gathered. I also want to look to protocol trace. To obtain it, please uncomment the following lines in the
Traces will be in the You may either attach them here, or send me directly to pzz@apevzner.com If you decide to send it directly, please notify me here too in case e-mail will fall to the spam folder |
scanimage-zeroconf.log Traces with debug. |
How many pages left in the feeder? |
5 or more I could try what a "ScannerStatus" request shows before the NextDocument request, maybe there is a "not ready" message or something. But only on Wednesday as I'm out of office now ;-) |
ScannerStatus very cleanly shows that ADF is out of documents:
Obviously it is firmware bug. Adding 1-second delay will slow-down scanning on devices that can do >60 pages per minute. Here I need to think a little bit... |
When scanning from ADF, Brother MFC-L2710DW returns HTTP 404 status after normally retrieving a couple of pages, and ScannerStatus returns ScannerAdfEmpty at this case, which leads to premature scan job termination with SANE_STATUS_NO_DOCS status Introducing a small delay between subsequent LOAD requests solves this problem To avoid performance regression on a very fast scanners, this delay has an upper bound as a fraction of the preceding LOAD query time
I've added a delay with upper bound based on a time taken by the preceding NextDocument request, so Brother should work, while very fast scanners will not be slowed down, Please fetch the latest source and retest, before I'll close this issue |
I had to test this immediately after returning home ;-) For the supported devices list: |
Idea with adaptive delay is obvious for everybody who was writing networking code for all his or her professional life :-) What is wrong with WSD? It is not offered in the list or offered, but it doesn't work? According to zeroconf log, your device supports WSD. However, if |
It is offered and when selected manually it did not work (don't know the exact error). The difference is only last time I used sane-airscan-ng-1590598308-0.x86_64.rpm, today I used sane-airscan-ng-1592844898-0.x86_64.rpm (I'm building those in my $HOME in OBS for ease of installing, and for testing I built them locally, thus the "-0" build number). The old version is commit 8392745, the new version is from today. But anyway, it seems fixed with WSD now, too :-) |
-ng currently is a little bit outdated, and I don't very often push there fixes from the stable branch. So I think I can close the issue, and add your device to the list. BTW, I've just created |
My Brother MFC-L2170DW works almost perfect with sane-airscan, in eSCL mode.
However, when scanning multiple pages from ADF, it most of the time aborts after 2 or 3 pages, with
This is on openSUSE Leap 15.2 Beta, no matter if I try sane-airscan or sane-airscan-ng packages from OBS.
To debug the issue, I wrote a simple scanning tool in Python: https://github.com/seife/airscan-simple
When scanning directly to PDF format, the output is all pages in one file, which always works fine, but the inital implementation had the same problem for multi-file (jpg format) scanning, aborting after a few pages.
I also found out, that scanning with resolution 600dpi seems to work more reliably.
Finally I found, that adding a short wait before retrieving /NextDocument fixed the issue. Maybe the brother firmware is not fast enough and immediately requesting the next page results in a 404.
this line https://github.com/seife/airscan-simple/blob/master/airscan-simple.py#L90 fixed it for me.
I added a one-second-sleep, but scanimage works with 600dpi (I guess the conversion takes slightly longer), I'd suspect that even a shorter wait would suffice. But since the scanning takes longer than a second anyway, this seems to be fine ;-)
The text was updated successfully, but these errors were encountered: