"Could not send data, aborting" on second scan

[PRBB28]

Installed on Debian 12 running on a virtual machine. Scanning locally using scanimage, no problems even if I do it multiple times.
But when I enable airsane and try to scan remotely on my mac, the first scan works and I receive the image, but if I scan again, my scanner app is stuck waiting for the image.

In the logs I found this message "Could not send data, aborting", but no indicator that it's an error.

attached is captured log running "sudo -u saned airsaned --debug=true --access-log=-"
airsend.log

[PRBB28]

Sorry mistyped the name of the log.

[SimulPiscator]

Thanks for your report. Unfortunately, the log you linked to is not an AirSane log.
To generate a log, please do the following:
sudo service airsaned stop
sudo -u saned airsaned --debug=true --access-log=-
Then copy-and-paste the output of the terminal.
Alternatively, do
sudo service airsaned stop
sudo -u saned airsaned --debug=true --access-log=- >/path/to/logfile 2>&1
to write output to a file.

[PRBB28]

Sorry for the late reply. And also sorry did not check the log I uploaded before.
Attached is the log out put using the command you specified. And this time I've checked it. :)
airsaned.log

[SimulPiscator]

Again thank you for your report. It helped me spot an issue with SANE backends that are not thread safe.
I fixed that issue by introducing a worker thread in which each job runs. So, hopefully your problem is gone with the latest commit (025da58).

[PRBB28]

The fix only partially solved the problem. Before, after scanning the first image, my iMac app gets stuck waiting on for the second image, clicking on cancel button does nothing. Now I can cancel and scan again. But still get stuck waiting on the second image scanned.

I still see "Could not send data, aborting" in the logs. It seems like there is a problem sending the second image.

To be able to scan again and receive the image, I have to restart airsane and my scan app.
airsaned.log

[SimulPiscator]

Thanks for the updated log. Could you send me a log without clicking cancel and scanning again? That would be quite helpful.

Edit: In the meantime, I added more detailed error logging to airsaned. It would be helpful if you could update to the latest version.

[PRBB28]

Mac OS built in Scanner app does not allow scanning again until current scan is completed. So I had to use a different app to be able to do what you want.

Mac OS built in app looks like this:

Here's the log using NAPS2 Scanning App which allows me to continue requesting for a scan without cancelling.
airsaned.log

[SimulPiscator]

Thanks for the log. I really have a hard time to analyze the issue from remote, so I appreciate your patience.
I made a small modification that should avoid the lots of "device busy" messages.

When I asked for a log "without clicking and scanning again", I actually meant to say "without doing anything else than clicking "scan" once". Sorry if that was not clear.

[PRBB28]

Sorry about that. Here's the log where I only clicked scan once. I went back to using MacOs Builtin Scanner App.
airsaned.log

[SimulPiscator]

Now the log looks fine. What happens if you feed the scanner more than one sheet of paper?

[PRBB28]

Ok, first of all, my scanner is a portable scanner and is fed manually one sheet at a time.

Before you added the worker thread, the scanner will not finish the scanning the second sheet. It stops nearly at the end, leaving the paper stuck in the scanner. And my scanning app also stuck waiting for the image of the second sheet to be sent.

After you introduce the worker thread, it would complete the scan of the second page, but my scanning app is still stuck waiting for the image to be sent.

Don't know if this would help but if found out that where the "Could not send data, aborting" is comming from.
It's in scanjob.cpp @ line 739, your flushing ostream and it is failing. If I read your code correctly, this ostream (from HttpServer Class If I'm not mistaken) is the one responsible for sending the data over to the client.

Sorry but my c++ is very very rusty, it's been a long time. And I haven't figured out why it's fails the second time it's flushed to send the image data over to the client.

[SimulPiscator]

Don't know if this would help but if found out that where the "Could not send data, aborting" is comming from.
It's in scanjob.cpp @ line 739, your flushing ostream and it is failing. If I read your code correctly, this ostream (from HttpServer Class If I'm not mistaken) is the one responsible for sending the data over to the client.

Sorry but my c++ is very very rusty, it's been a long time. And I haven't figured out why it's fails the second time it's flushed to send the image data over to the client.

You are mostly right except that the ostream is a new one for each HTTP request so the state that makes it fail after the first sheet cannot be located there.

Also, for a std::ostream, practically the only way to fail on output is if the associated output file fails in some way (socket in this case).

May I ask which architecture your Mac has? On my Intel Mac, when scanning multiple "sheets" from the SANE test backend, I cannot reproduce this issue. In fact, I have never seen the "Could not write data" error before either.

I have now added some code to immediately terminate the scanning session when "Could not send data" occurs. This may result in a slightly improved user experience.

[PRBB28]

I'm using an intel mac. Airsane is running on a linux container with scanner connected via usb passhtrough.

Can you do me a favor and try this, in the hopes that we might replicate the problem?
Can you start up airsane then scan from Mac App, but do not insert any document.
Hopefully doing this will cause the Mac App to get stuck wating for the image from the scanner. Same as what I'm experiencing.
Click cancel and Try scanning again but this time insert a document in the scanner. This should cause Airsane to fail, in sending the Image, genereting the "Could not write data" in the logs.

I've discovered that the same issue can be replicated this way. Maybe doing it this way will trigger this bug in your setup.

[SimulPiscator]

Great, thank you! Unfortunately, I don't have a physical ADF scanner, and the SANE test backend works fine for me.

[SimulPiscator]

I did discover an oversight in the basic/fdbuf code, which did not handle the EINTR error condition on read()/write() properly, and could lead to the request's ostream getting "bad". Maybe the issue is fixed now.

[PRBB28]

Still the same. Another thing I notice while testing, if I feed a sheet immediately after this first sheet is finished, I see a single pdf file with both image in it in my scan directory, but the second image does not appear in the app screen like the one I posted above. If I switch to jpeg, I see the second image, and see two jpeg files in the directory where the app saves the scan. If I wait until the scanner detects it's out of document to scan, thats when I don't receive the second image. My scanner has no indicator for this I just wait for a few seconds. Here's the basic summary

PDF Scanning Scenario:

1. Scan first page, then feed the second immediately-> scanner continues scanning the second page -> I receive pdf file with two image in it.
2. Scan first page, then wait a few seconds before inserting second sheet -> scanner grabs the sheet but does not continue the scanning, I have the click on the scan -> I receive pdf file with just one image in it. ->Scanner app stuck waiting for the image. (Only cancel button is available)

Jpeg scanning Scneario :

1. Same procedure as above, but I receive two jpeg files and second image replaces the first image in the app screen.
2. Same procedure as above, but I receive only one jpeg file, second image does not appear in the app screen.

Here's the log. For Scenario 1 PDF.
airsaned_pdf_scenrio_1.log
Scenario 2 PDF.
airsaned_pdf_scenrio_2.log

For Scenario 1 JPEG :
airsaned_jpeg_scenario_1.log
Scenario 2 JPEG :
airsaned_jpeg_scenario_2.log

[SimulPiscator]

Thanks for your extensive description. I added some error logging to obtain information about why the output stream is broken.
Could you send me a log file for the error condition recorded with the updated code? Thank you so much!