Blank scans in sheet-feed operation

[Steven Hirsch]

For no reason that I can fathom, scans from my UMAX Astra 2400S are coming up blank when in sheetfeeder mode. They are fine in flatbed mode. It is not a device problem! All other scanning programs (e.g. simple-scan, xsane) produce images from the sheet-feeder with no errors or signs of a problem.

This used to work fine. I have tried deleting my .gscan2pdf file and starting from scratch with no success. I've also noticed that I no longer have the ability to adjust black-threshold or any other parameters from the scan dialog. These also used to work.

[Steven Hirsch (snhirsch)]

Sorry, distribution is Lucid. Application version is 0.9.29-1ubuntu1.

[Jeffrey Ratcliffe (jeffreyratcliffe)]

That is a very old version. Can you try the latest?

[Steven Hirsch (snhirsch)]

Here is a capture of the log file. Hopefully this will explain why the options are missing? I don't recall ever changing the font end - I'm about 99% sure this one used to allow me to play with threshold and brightness.

[Jeffrey Ratcliffe (jeffreyratcliffe)]

Threshold and brightness both have cap=37. cap is the capability flag. If you look at the SANE API[1], 37 is INACTIVE + SOFT_DETECT + SOFT_SELECT

The question is then why the options are inactive. Unfortunately, the log doesn't make it clear what options have been set.

Try changing the "Scan Mode" option and see if that affects things.

[1] http://www.sane-project.org/html/doc011.html

[Steven Hirsch (snhirsch)]

Sorry for the delay getting back. Well, the original problem is back again. I have changed nothing whatever in the system configuration and sheet-fed scans are returning blank pages. Flatbed on the same device works perfectly.

I tried all the front-end "scan mode" selections and all are broken in the same manner. I am seeing these in the log and wonder if it's not related?

perl: io/hpmud/pp.c 627: unable to read device-id ret=-1

[Steven Hirsch (snhirsch)]

More information: I think the error message was a red herring. It appears to be an artifiact of the initial device probe and vanishes if I uninstall all the HPLIP related packages.

I'm growing suspicious of something in the SANE initialization process. I discovered by accident that if I run a scan using Xsane, exit that program and re-start gscan2pdf it springs into life and I can run sheetfeeder scans. I think this is why updating my version of gscan2pdf appeared to fix things last time around. I had tried with Xsane after fruitless attempts using gscan2pdf and never went back to the latter until after I upgraded.

[Jeffrey Ratcliffe (jeffreyratcliffe)]

On 22 April 2012 16:53, Steven Hirsch <email address hidden> wrote:
> I'm growing suspicious of something in the SANE initialization process.

In recent versions, there is an option in Edit/Preferences "Cycle SANE
handle after scan", which reinitialised the scanner after each scan. I
added this because my HP all-in-one (via HPLIP) wouldn't spit out the
last page from the ADF until the scanner process finished. Perhaps it
affects your problem too.

[Steven Hirsch (snhirsch)]

Unfortunately that does not help - I tried it. Something that Xsane is doing appears to be the trick. Annoyingly, all this nonsense started "out of the blue". For almost a year the scanner worked fine without any gyrations. I wonder if there was a SANE update that hosed things?

[Jeffrey Ratcliffe (jeffreyratcliffe)]

Turn on logging, by specifying the --log=log option when you start
gscan2pdf from the command line. Switch to the scanimage frontend in
Edit/Preferences, then read from the log the scanimage call which
gscan2pdf used when scanning.

If you can reproduce the bug with scanimage from the command line,
then it can be fixed or worked around in SANE, and I can see how to
work around it with gscan2pdf.

[Launchpad Janitor (janitor)]

[Expired for gscan2pdf (Ubuntu) because there has been no activity for 60 days.]