[sane-devel] saned/Epson problems - second try

[John Coppens]

Hello people.

A problem I reported last year. In short: I run saned from inetd, with the
EPSON backend. Xsane seems to run erratically, and produces 'Invalid
argument' error windows. Henning proposed a few tests which I could just
now realize. Below are the comments and some log extracts:

> On Sat, Dec 07, 2002 at 01:47:17AM -0300, John Coppens wrote:
> > Xsane starts up well, even though I'd rather have have it _not_
> > check the parallel port, if I mean to have it run through the
> > daemon. I didn't find how to do that.
> 
> I have never tried that but you could play with permissions of the
> epson.conf file and/or libsane-epson.so.version. Setting them so only
> saned can load the backend may work.
> 
> Another way would be to link xsane to the net backend directly,
> without using libsane-dll.
> 
> > But then, communication between saned and xsane seems to be very
> > unreliable. Erratically, I get the famous 'invalid argument'
> > messages, when I try for example to change the mode from gray to
> > color, or change the resolution. It's just unpredictable. Sometimes
> > it works, sometimes not. I restarted xsane many times, and each time
> > it behaves differently. Sometimes it works completely, sometimes not
> > al all.
> 
> Can you go on after such an error without restarting xsane? Or does
> every other action fail after the first error? Does scanning work,
> even if errors occured before? Do the errors onlöy occur when
> setting/reading options?
> 
> > All versions are the last ones - fresly downloaded. Kernel is
> > 2.4.18, and the scanner is an Epson ActionScanner II (GT-5000M). All
> > points to unreliable comm between xsane and saned...
> 
> The communication flow is like this:
> 
> xsane <- linking -> libsane-dll <- dynamic loading -> libsane-net <-
> network network -> saned <- linking -> libsane-dll <- dynamic loading
> -> libsane-epson
> 
> I guess it doesn't happen when you don't use saned, but access the
> epson backend directly?
> 
> Do you get the same problems with other frontends (xscanimage,
> quiteinsane, scanimage)? No? -> xsane problem (unlikely)

I've tried: xscanimage (same error), scanimage (with several options
such as --mode Color, --mode Gray, --mode Binary (!NO ERRORS HERE! no
errors in any mode) Didn't have QuiteInsane... Am compiling Qt now to
install it. Machine is slow, and won't be able to test today.

> 
> Does it happen with other backends? If you don't have other scan
> hardware, try the "test" backend. It does also happen? --> bug in
> saned or net. I think that's unlikely, too, but I'm biased. We had
> bugs in saned/net before but they resulted in crashes.
> 
> You can try if it happens in debug mode, too. Comment out saned in
> inetd.conf, restart inetd, and run saned in daemon mode from the
> This will also enable debug messages. If the problem occurs in this
> mode, too, you can also set epson debugging:

running saned -d128... 

1) xscanimage runs without problems now?
2) starting xsane stops saned! This appears on screen:

[saned] process_request: got request 6
[saned] process_request: waiting for request
[saned] process_request: got request 3
[saned] process_request: waiting for request
[saned] process_request: got request 10
[saned] quit: exiting

Restarted saned -d128, then xsane, runs fine but the problems changing
the mode (Gray/Color/etc) reappear on screen (with the 'Invalid argument'
messages). No indication (error) from the -d128.

Exiting xsane stops saned again.

> 
> SANE_DEBUG_EPSON=128 saned -d128

The error (invalid argument) appears when running xsane. No diagnotics on
the screen. Just the normal comm:

[saned] process_request: got request 5
[saned] process_request: waiting for request
[saned] process_request: got request 5
[saned] process_request: waiting for request

No weird messages on /var/log/debug either:

Jan  3 20:27:58 susan saned[10667]: init: access by saned-user at 127.0.0.1
accepte d
Jan  3 20:28:02 susan saned[10667]: [epson] Requesting extended status
Jan  3 20:28:02 susan saned[10667]: [epson] No error
Jan  3 20:28:02 susan saned[10667]: [epson] Checking for ADF: (00)
Jan  3 20:28:02 susan saned[10667]: [epson] Checking for TPU: (00)
Jan  3 20:28:02 susan saned[10667]: [epson] Device name = GT-5000M


> 
> 
> SANE_DEBUG_NET=255 xsane

(This is the end of the initial startup - there are no error messages)
[net] sane_get_option_descriptor: option 38
[net] sane_control_option: option 38, action 0
[net] sane_control_option: remote control option
[net] sane_control_option: done (Success)
[net] sane_get_parameters
[net] sane_get_parameters: remote get parameters
[net] sane_get_parameters: returned status Success
[net] sane_get_option_descriptor: option 10
[net] sane_get_option_descriptor: option 10
[net] sane_control_option: option 10, action 1
[net] sane_control_option: remote control option
[net] sane_control_option: done (Success)

(On changing the scan mode I get the following)
[net] sane_get_option_descriptor: option 2
[net] sane_get_option_descripter: getting option descriptors
[net] fetch_options: 0x80eb450
[net] fetch_options: 47 option descriptors cached... freeing
[net] fetch_options: get_option_descriptors
[net] fetch_options: copying 47 option descriptors
[net] fetch_options: 47 options fetched
[net] sane_control_option: option 2, action 1
[net] sane_control_option: remote control option
[net] sane_control_option: done (Invalid argument)
[net] sane_get_option_descriptor: option 2

FINAL NOTE:

Seems that the error is somewhat erratic. When just started, xsane gives
the problems described above. Now, strangely, after playing around a bit
with xsane, (Entering in the setup, though not changing anything),
suddenly the mode change started working!

Changed several times, scanned in different modes - all ok. Did not have
the time to start all over again. Will do that next time... If it weren't
that xscanimage gives the same error, I'd say it was an xsane problem. Now
I'm completely confused.

Any suggestions are appreciated!

John