Delayed Print Action #5251
Comments
|
We don't provide drivers for this particular printer, but it is possible you can add a USB quirk rule for it. Run "lsusb -v" to get the vendor and model codes, and then make a file in /usr/share/cups/usb with the following: 0xVENDOR 0xMODEL unidir |
|
Thanks so much for your replies. I have done as instructed, inserted '0x0519 unidir' into a file in /usr/share//cups/usb/, and the behavior of the printer has changed. If I now print 3 copies of an extremely small text file, it works perfectly. However, as soon as I increase the size of the text file and print multiple copies, a different issue seems to occur. The printer jams, and the job seems to disappear. Please see error log below : I [20/Feb/2018:21:21:06 +0200] Saving subscriptions.conf... Further advice would be greatly appreciated. |
|
Sigh, that sounds like the printer doesn't actually implement the USB printer class properly - as soon as it falls behind it sounds like it starts dropping data. Not sure what can be done to resolve this, but I'd try to get the manufacturer involved... |
|
Ok, thanks for the help. I will have to keep at it. Moving forward though, do you have any recommendations for thermal printers that work well with the CUPS system ? |
|
The Zebra printers I've worked most recently with have all been solid. In the (somewhat distant) past I used Dymo printers for printing hundreds of smaller labels on a daily basis, however none of the models I used back then are still sold today... Both are supported by the bundled CUPS label printer driver. |
|
Ok great, will look into those. Whats strange for me is that I have used this exact same Star printer on Ubuntu 14 running CUPS 1.5.2 and it is working flawlessly up till this day. I was wrong to assume the same with the most updated software. Anyways, thanks once again... |
|
The backend has probably changed from using the kernel "lp" module to the libusb-based backend and lower-level kernel USB driver. Plus you are using a newer Linux kernel - probably what worked before due to a timing or compatibility hack no longer works... :/ |
|
@Arvish12 Have a look at What kind of USB port is used at your computer? At least for USB scanners there are known issues with the Nowadays "xhci_hcd" kernel driver/module issues (a.k.a. "USB 3") Regarding how to get kernel related USB messages, In particular see Regarding "USB 2.0 (black) and USB 3.0 (blue)": Neither the color nor what the port is labeled on the computer is reliable regarding what kernel driver is used for the port. Only the "lsusb -t" output shows what kernel driver is used. For example all USB ports on my testing machine have same dark color. Also the "super speed" (USB 3) labeled ports are basically black. Their exact color is "very dark" but not "100% black" and neither blue (USB 3.0) nor teal blue (USB 3.1), cf. https://en.wikipedia.org/wiki/USB#Colors On my testing machine xhci_hcd is used for all USB ports where I can connect devices (i.e. all external USB ports). If USB 3 (i.e. the xhci_hcd kernel driver) is the root cause, |
- Fixed a compile issue when PAM is not available (Issue #5253) - Documentation fixes (Issue #5252) - Star Micronics printers need the "unidir" USB quirk rule (Issue #5251) - The scheduler now supports using temporary print queues for older IPP/1.1 print queues like those shared by CUPS 1.3 and earlier (Issue #5241) - The `cupsRasterWritePixels` function did not correctly swap bytes for some formats (Issue #5225) - Added a USB quirk rule for Canon MP280 series printers (Issue #5221) - The `ppdInstallableConflict` tested too many constraints (Issue #5213) - More fixes for printing to old CUPS servers (Issue #5211) - The `cupsCopyDest` function now correctly copies the `is_default` value (Issue #5208) - The scheduler did not work with older versions of uClibc (Issue #5188) - The scheduler now substitutes default values for invalid job attributes when running in "relaxed conformance" mode (Issue #5186) - Fixed PAM module detection and added support for the common PAM definitions (Issue #5185) - Fixed a journald support bug in the scheduler (Issue #5181) - The cups-driverd program incorrectly stopped scanning PPDs as soon as a loop was seen (Issue #5170) - Fixed group validation on OpenBSD (Issue #5166) - Fixed the `ippserver` sample code when threading is disabled or unavailable (Issue #5154) - The `cupsEnumDests` function did not include options from the lpoptions files (Issue #5144) - The `SSLOptions` directive now supports `MinTLS` and `MaxTLS` options to control the minimum and maximum TLS versions that will be allowed, respectively (Issue #5119) - The scheduler did not write out dirty configuration and state files if there were open client connections (Issue #5118) - The `lpadmin` command now provides a better error message when an unsupported System V interface script is used (Issue #5111) - The `lp` and `lpr` commands now provide better error messages when the default printer cannot be found (Issue #5096) - No longer support backslash, question mark, or quotes in printer names (Issue #4966) - The CUPS library now supports the latest HTTP Digest authentication specification including support for SHA-256 (Issue #4862) - The `lpstat` command now reports when new jobs are being held (Issue #4761) - The `lpoptions` command incorrectly saved default options (Issue #4717) - The `ppdLocalizeIPPReason` function incorrectly returned a localized version of "none" (rdar://36566269) - TLS connections now properly timeout (rdar://34938533) - The IPP backend did not properly detect failed PDF prints (rdar://34055474)
|
OK, I'm going to close this bug as "fixed" as much as we can fix it on our end. Please let me know if there are other changes we can make to improve the performance of these printers... |
Hello out there. Help required.
I am using a Star Micronics thermal printer TSP654 (STR_T-001) via USB on Ubuntu 16.04.
I have built the driver as instructed from the vendor. When printing a small text file, printing happens immediately with no error. As soon as the text file is larger OR I choose to print multiple copies, the printing process seems to slow down dramatically.
The CUPS erro_log shows countless entries as follows :
D [19/Feb/2018:23:06:27 +0200] [Job 38] Read 9 bytes of back-channel data...
D [19/Feb/2018:23:06:27 +0200] [Job 38] Read 9 bytes of back-channel data...
D [19/Feb/2018:23:06:27 +0200] [Job 38] Read 9 bytes of back-channel data...
D [19/Feb/2018:23:06:27 +0200] [Job 38] Read 9 bytes of back-channel data...
D [19/Feb/2018:23:06:27 +0200] [Job 38] Read 9 bytes of back-channel data...
D [19/Feb/2018:23:06:27 +0200] [Job 38] Read 9 bytes of back-channel data...
D [19/Feb/2018:23:06:27 +0200] [Job 38] Read 9 bytes of back-channel data...
D [19/Feb/2018:23:06:27 +0200] [Job 38] Read 9 bytes of back-channel data...
D [19/Feb/2018:23:06:27 +0200] [Job 38] Read 9 bytes of back-channel data...
D [19/Feb/2018:23:06:27 +0200] [Job 38] Read 9 bytes of back-channel data...
And after some time, sometimes 2-3 minutes, sometimes more, the document eventually prints. What on earth could be causing CUPS to only read 9 bytes of data at a time ???
The text was updated successfully, but these errors were encountered: