search

OpenPrinting / ipp-usb

ipp-usb -- HTTP reverse proxy, backed by IPP-over-USB connection to device
BSD 2-Clause "Simplified" License
129 stars 11 forks source link

ipp-usb needs to be restarted after Pantum M6559NW is reconnected #66

Open gustingonzalez opened 1 year ago

gustingonzalez commented 1 year ago

Hello,

I'm experiencing an issue with a Pantum M6559NW, where the scanner and printer functions stop working after disconnecting and reconnecting the device. Checking the logs of the ipp-usb execution, I found the following:

> HTTP[008]: GET http://localhost:60000/eSCL/ScannerCapabilities
  USB[1]: connection allocated, 1 in use: --- a-- ---
  HTTP[008]: connection 1 allocated
! USB[1]: send: libusb_bulk_transfer: Input/Output Error
! HTTP[008]: libusb_bulk_transfer: Input/Output Error
  USB[1]: connection released, 0 in use: --- --- ---
! ESCL: eSCL: Get "http://localhost:60000/eSCL/ScannerCapabilities": libusb_bulk_transfer: Input/Output Error
[...]
> HTTP[009]: POST http://localhost:60000/ipp/print
> HTTP[009]: request body: got 173 bytes; EOF
> HTTP[009]: body is small (173 bytes), prefetched before sending
  USB[2]: connection allocated, 1 in use: --- --- a--
  HTTP[009]: connection 2 allocated
! USB[2]: send: libusb_bulk_transfer: Input/Output Error
! HTTP[009]: libusb_bulk_transfer: Input/Output Error
  USB[2]: connection released, 0 in use: --- --- ---
> HTTP[009]: POST http://localhost:60000/ipp/print
! HTTP[009]: libusb_bulk_transfer: Input/Output Error

To try to solve the issue, I set the max-usb-interfaces to 1. While this did work, I noticed that it resulted in the loss of the job cancelling feature, which is required to prevent the printer from remaining in the 'printing' state after the document is printed (as detailed in this issue).

Since limiting the USB interfaces to 1 is not a feasible solution if you want to implement the aforementioned workaround, I tried re-run ipp-usb when the printer is reconnected. This solution works well and provides a similar effect without the need to limit the USB interfaces.

I tested both the ipp-usb_0.9.23-1+53.1_amd64.deb version and a compiled one from the master branch, and observed same behavior in both cases.

Please let me know if you need any more information, or if there is anything I can contribute.

Thanks in advance!

alexpevzner commented 12 months ago

Hi @gustingonzalez,

looks like if you connect the printer when ipp-usb is running, ipp-usb begins device initialization immediately, when device is not ready yet. While if you connect the printer and then start (or restart) the ipp-usb daemon, device has enough time to initialize itself before the first request comes

could you please play a little bit with device quirks parameters? The most promising is, probably, init-delay and, may be, init-reset