6

I've seen tons of posts asking this and similar questions on various forums, but no one seems to be able to provide a solution.

The basic problem goes like this:

Printing worked fine on [Insert Old Version of Linux Distro], but after updating to [Newer version of Linux Distro], there's now a [5,10,15] second delay between sending a file to the print cue and when the printer actually starts printing.

In my particular case, printing started immediately on Ubuntu 8.04, but after upgrading to 10.04, has a 10 second delay. I'm doing this on Ubuntu Server, printing with the lpr command, but the problem is present on 10.04 desktop as well. From what I've read, it also affects newer versions of MOST linux distros. Fedora, OpenSUSE, Arch, etc.

The printers are all network printers. Printing from Windows is also immediate. The light on the printer starts blinking immediately, but nothing comes out for 10-15 seconds.

Ubuntu 10.04 uses CUPS 1.4.3. I thought it might be a bug in CUPS, so I compiled CUPS 1.4.5 (latest stable) to replace Ubuntu's 1.4.3. But there's still a delay.

Any idea what might be causing this? Or a way to troubleshoot the problem to figure out what's causing it?


UPDATE: I set loglevel to debug and got about 660 lines of output in my log for a single job. The test file I sent took 10 seconds from the time it was added to the cue to when it came out.

I won't post the whole thing here (unless you really want it!), but here's the highlights:

The job is cued and a bunch of things happen in that same second. The last line for that second is:

D [28/Nov/2010:14:44:19 -0500]
   Discarding unused printer-state-changed event...

The next log line occurs a full 4 seconds later:

D [28/Nov/2010:14:44:23 -0500]
  [Job 3071] prtGeneralCurrentLocalization type is 0, expected 2!

So we have a 4 second delay here for some reason.

1 second latter we get:

D [28/Nov/2010:14:44:23 -0500] PID 15448 (/usr/lib/cups/filter/pdftoraster) exited with no errors.
D [28/Nov/2010:14:44:24 -0500] [Job 3071] Wrote 8192 bytes of print data...
D [28/Nov/2010:14:44:24 -0500] [Job 3071] Read 8192 bytes of print data...
I [28/Nov/2010:14:44:24 -0500] [Job 3071] Printing page 1, 57% complete...
I [28/Nov/2010:14:44:24 -0500] [Job 3071] Printing page 1, 59% complete...
D [28/Nov/2010:14:44:24 -0500] Discarding unused job-progress event...
D [28/Nov/2010:14:44:24 -0500] Discarding unused printer-state-changed event...
I [28/Nov/2010:14:44:24 -0500] [Job 3071] Printing page 1, 60% complete...

Which repeats until:

I [28/Nov/2010:14:44:26 -0500] [Job 3071] Printing page 1, 99% complete...
D [28/Nov/2010:14:44:26 -0500] Discarding unused job-progress event...
D [28/Nov/2010:14:44:26 -0500] Discarding unused printer-state-changed event...
I [28/Nov/2010:14:44:26 -0500] [Job 3071] Ready to print.

Then it goes on to:

D [28/Nov/2010:14:44:26 -0500] [Job 3071] Wrote 8192 bytes of print data...
D [28/Nov/2010:14:44:26 -0500] [Job 3071] Read 8192 bytes of print data...

Over and over again until:

D [28/Nov/2010:14:44:29 -0500] [Job 3071] Read 3361 bytes of print data...
D [28/Nov/2010:14:44:29 -0500] [Job 3071] Wrote 3361 bytes of print data...
I [28/Nov/2010:14:44:29 -0500] [Job 3071] Print file sent, waiting for printer to finish...

Which is the point at which the printer actually starts producing output. A full 10 seconds later.

2
  • If you queue two jobs simultaneously, does the second job have an additional 10-15s wait? or does it come out immediately after the first?
    – pjz
    Dec 7, 2010 at 16:08
  • Each job has the delay. I've managed to shave 4 seconds off via a comment from one of the CUPS devs on the official mailing list. I'll post his answer below.
    – Nick
    Feb 18, 2011 at 7:10

5 Answers 5

3

I experience some of the same. I'm not sure if this is the same problem as you, but we experince that with receipt-printers, some of them suddenly started having a 4 seconds delay when printing, while others came straight away.

This was after an Cups upgrade (Slackware linux).

After a lot of debugging, we have found that the printers supporting SNMP doesn't have the delay, while printers not supporting SNMP does have the delay.

It seems cups, after the upgrade, is trying to fetch info from the printer by SNMP before sending the actual printjob.

I'm now looking for a way to disable this feature... Will try to write back if I find a solution.

I should mention that we are using raw/socket connection to these printers. I see RedHat has a reported bug about this, but I'm not allowed to view it (BZ#709896)

I can't really find out how I can disable the SNMP-communication in Cups. :\

1
  • 1
    Ah, I found the solution to our problem! cups.org/str.php?L3809 We need to upgrade from Cups 1.4.6 to at least Cups 1.4.7 !
    – jornonet
    Jul 5, 2012 at 13:31
3

A potential unrelated answer to your question but was certainly the answer to my question was for a local USB thermal printer -- why was it causing a delay of 5 seconds between prints.

The solution turned out to be that not all USB printers should be setup as bi-directional communication like CUPS wants to do. So setting up a "quirk" for the printer in the /usr/share/cups/usb area of cups to include the specific printer "ID"and setting flags such as "unidir" "no-reattach" "soft-reset" seemed to entirely fix the issue for me. Hopefully anyone looking for the same issue can save a few hours debugging into the cups code to understand what was obvious once i keyed in on the debug output that said it was waiting for the USB read thread to exit (apparently 5 seconds).

3
  • 1
    Could you add more detail about how you addad the flags and what I should edit ? I have the same setup than you and I would like to try your solution. Dec 22, 2020 at 14:02
  • @ChristopheChenel I just found it. Use an editor to edit the file /usr/share/cups/usb/rg.cups.usb-quirks . Find your printer's vendor and product IDs using lsusb per instructions in the file you are editing. Add a line in this file with the vender and product IDs of your printer prepended with '0x' and separated by a single space. You'll have to be sudo to save it. Cheers!
    – Conrado
    Aug 15, 2023 at 19:55
  • Anyway, thanks a lot! as this answer saved me a lot of headache. Also, for the record, this still is the answer for some printers in 2023. I'm using a Star TSP800II.
    – Conrado
    Aug 17, 2023 at 22:27
1

I would suggest looking at the following post in ubuntuforums, as they seem to have a communication issue with the printer too.

http://ubuntuforums.org/showthread.php?t=1101273

hope that helps, RayQuang

1
  • I think that's an issue with delay between pages? And I can't use a generic printer since my problem printer is a 4x6 thermal laser. It won't work correctly with a generic .ppd.
    – Nick
    Feb 18, 2011 at 7:08
1

I have same experience with user127222. For some printers with no SNMP supported, the print jobs will have 4 seconds delay. After study those code in CUPS:

  if ((ppd = ppdOpenFile(getenv("PPD"))) == NULL ||
      ((ppdattr = ppdFindAttr(ppd, "cupsSNMPSupplies", NULL)) != NULL &&
       ppdattr->value && _cups_strcasecmp(ppdattr->value, "true")))
  {
    ppdClose(ppd);
    return;
  }

I find that I could disable these SNMP requests by updating PPD file for that printer. Using:

*cupsSNMPSupplies: False

Ref: CUPS PPD Extensions

1

Using a POS USB printer, I fixed the problem with this :

Stop the cups service

service cups stop

Edit the printers.conf file

sudo nano /etc/cups/printers.conf

scroll to your printer and add at the last line of the wanted printer configuration this line:

Option usb-unidir true

Restart cups service

service cups restart
1
  • 1
    This worked like a charm for me with a thermal POS printer. Jan 14, 2021 at 9:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .