On Mon, 2004-08-30 at 23:22, Ren=C3=A9 Rebe wrote: > Hi, >=20 > sorry for the delay - at least this week I'm =C3=BCber-busy again ... >=20 > > OK, log attached with SANE_DEBUG_AVISION=3D7. Used xsane to produce t= he > > problem. The scenario was as follows: > >=20 > > 1. Reboot > > 2. Correct scan > > 3. Wait half an hour > > 4. Incorrect scan, stopped half way through with this horrible noice. > > 5. Pulled the plug. > >=20 > > The scan was performed on a full A4-size document. If I reduce the sc= an > > to, say, 5 by 5 mm the problem never occurs. > >=20 > > Please let me know if you also need to see the image. >=20 > Ok, the wait_4_light() function timed out. Can you try if the scanner=20 > just needs yet more time to recover from the energy saving mode? Go to=20 > the wait_4_light() function in avision.c (depending on the version of=20 > the file) around line 1941. When you scroll thru the function you modif= y=20 > the for() loop testing for the warmup to wait longer, maybe 667 seconds= =20 > instead of current 90 ... ;-) Patch: >=20 > Index: avision.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- avision.c (revision 133) > +++ avision.c (working copy) > @@ -1962,7 +1962,7 @@ > set_double (rcmd.datatypequal, dev->data_dq); > set_triple (rcmd.transferlen, size); >=20 > - for (try =3D 0; try < 90; ++ try) { > + for (try =3D 0; try < 667; ++ try) { >=20 > DBG (5, "wait_4_light: read bytes %d\n", size); > status =3D avision_cmd (&s->av_con, &rcmd, sizeof (rcmd), 0, 0,=20 > &result, &size); >=20 > (Never tried this with Thunderbird and my new IMAP setup - so no idea i= f=20 > thiis inlien patch has mangled tabs ...) >=20 > But when some scanners really need _that much_ time to recover, I bet I= =20 > get other users balming the frontend to hang and I should think about=20 > some way to report this less annoyingly hanging ...
OK, I'll do this additional test, but I fear wait_4_light() will wait forever. As I see it the scanner performs correctly after reboot, then after the lamp has cooled off and no new reboot performed then the disaster happens. It's like a reset is missing. I'll test if this assumption is correct, but it takes some time because the lamp should have ample time to cool off and unfortunately I have very little time now. I'll see if I can squeeze in the time for the test though. --=20 Regards, Erik P. Olsen