Response from brother. "Hi Jeff.
Any type of sharing feature on a USB model is not supported by brother. Most questions we received for this are of a Microsoft nature, but the same policy applies to other OS's as well. If you are looking to have a machine work on multiple PC's, I recommend looking into a Network model like MFC-J485DW or something from the same series." Hmmm, looks like I need to restate the problem. On Fri, Jan 12, 2018 at 7:55 AM, Jeff Sadowski <jeff.sadow...@gmail.com> wrote: > My code is simply calling scanimage the way I posted here already. > Running the same commands by hand results in the same behaviour. I > have my code write the command it runs in a file called ran.txt, so I > can examine it and run it. I'm just using php to open a 3 pipe method > of running scanimage. it is actually running it under "script" which > allows scanimage to continually write to stdout/stderr without > blocking which gets written to a stdout.txt and stderr.txt files. I > also implemented the ability to send ctrl-c using the 3rd input pipe. > So if my loop that is reading the pipes sees that a certain file > exists and is still running it will send a ctrl-c. My frontend starts > this php script and detaches and then reads it's output files to see > what is going on it also continually loads the image being created by > scanimage. I get the latest page number from stdout.txt/stderr.txt and > the name of the file from my rant.txt looking for '--batch= and the > matching quote and replace all %d with the last page number and then I > have my image retrieve send that file. :-) > > On Fri, Jan 12, 2018 at 4:07 AM, Olaf Meeuwissen > <paddy-h...@member.fsf.org> wrote: >> Hi again, >> >> Jeff Sadowski writes: >> >>> uning sane -l -d128 -e I am able to see the following error. >> >> This >> >>> [saned] do_scan: done, status=End of file reached >>> [saned] process_request: waiting for request >>> [saned] process_request: bad status 22 >>> [saned] quit: exiting >> >> is probably due to the error you get on the other end >> >>> scanimage: scanning image of size 1648x2314 pixels at 24 bits/pixel >>> scanimage: acquiring RGB frame >>> Progress:98.8% >>> scanimage: min/max graylevel value = 11/255 >>> Application transferred too few scanlines >> >> which indicates that the image acquisition loop ended prematurely for >> some reason. While saned will happily continue to serve requests, how >> the backend and scanner react to this depends on the scanner's firmware >> and the backend's implementation. It may very well be that the scanner >> expects more read requests and refuses to reply to anything else while >> the backend won't send any of those but instead tries to start a new >> scan in vain. >> >> Based on what you wrote so far, I think this is a bug in the third party >> brother backend you seem to be using. The only people that can help you >> with that are the brother backend developers. There is nothing the SANE >> developers can do about it. >> >> That said, are you sure *your* code is doing the right thing? That is, >> does it read data until sane_read() returns SANE_STATUS_EOF? Or is it >> just reading the number of pixels expected based on the results of a >> sane_get_parameters() before you call sane_start()? The latter is the >> *wrong* way to read image data. >> >> Hope this helps, >> -- >> Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27 >> GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 >> Support Free Software https://my.fsf.org/donate >> Join the Free Software Foundation https://my.fsf.org/join -- sane-devel mailing list: sane-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org