slow photo printing since upgrading Feisty to Gutsy
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ghostscript (Ubuntu) |
Fix Released
|
Undecided
|
Craig |
Bug Description
Binary package hint: ghostscript
Since upgrading from Feisty to Gutsy, it now takes several minutes for a 4x6 photo to be sent to my printer. In Feisty, this took only a few seconds. The printer applet in the top panel says the print job is "processing". Running top shows user ls process gs and process usb each using 49+% of cpu. Standard text documents and test pages seem to print at normal speed. Only photo printing is affected. I am using the turboprint driver for a Canon i960 printer. The Turboprint people think it's a cups problem with its usb backend.
Till Kamppeter (till-kamppeter) wrote : | #1 |
Martin G Miller (mgmiller) wrote : | #2 |
I have tried the first 2 things you suggested above, I added the line FileDevice yes without quotes to the end of the file. however, I cannot modify my print queue as you suggest. I cannot open the file to edit it. There is a red - icon next to it and it says no known file type if I try to open it as sudo or as regular user. Also, how do I know what <name of your print queue> is?
After doing only the first 2 things, there is no change in print behavior or in what is displayed in top.
Thank you for your speedy reply
Till Kamppeter (till-kamppeter) wrote : | #3 |
To edit /etc/cups/
sudo gedit /etc/cups/
In the editor window coming up then add the line
FileDevice yes
to the end of the file. Restart CUPS with the command
sudo /etc/init.d/cupsys restart
then.
For modifying the print queue execute the command
lpstat -v
at first. You get one line for each print queue on your system. The name of the queue is the word between "device for " and the colon (":"). Replace the "<name of your print queue>" in
lpadmin -p <name of your print queue> -E -v file:/dev/usblp0
by the name of the queue for your Canon printer,
Martin G Miller (mgmiller) wrote : | #4 |
OK, thank you for the explicit instructions. I did this for the 4 instances of the i960 printer that I have defined on my system. (one for each paper size and photo paper vs. plain paper)
marty@tux:~$ lpstat -v
device for DeskJet-895C: smb://home/
device for i960_4x6_photo: usb://Canon/i960
device for i960_5x7_photo: usb://Canon/i960
device for i960_8.5x11_photo: usb://Canon/i960
device for i960_tux: usb://Canon/i960
device for PDF: cups-pdf:/
marty@tux:~$ lpadmin -p i960_4x6_photo -E -v file:/dev/usblp0
marty@tux:~$ lpadmin -p i960_5x7_photo -E -v file:/dev/usblp0
marty@tux:~$ lpadmin -p i960_8.5x11_photo -E -v file:/dev/usblp0
marty@tux:~$ lpadmin -p i960_tux -E -v file:/dev/usblp0
marty@tux:~$
It now takes about 45 seconds to get the printer going instead of 2 minutes. Under Feisty, this was no more than 10 seconds. top no longer mentions usb cpu use. gs now shoots up to 98% cpu and the resulting photos have all the colors way off, shifted heavily towards red. At least, the other way, it was slow, but the pictures looked good. These are unusable. How do I undo the lpadmin command? Do you have any other suggestions?
Thank you for your rapid response to this issue.
Till Kamppeter (till-kamppeter) wrote : | #5 |
To undo the lpadmin command do for each print queue
lpadmin -p <name of your print queue> -E -v usb://Canon/i960
Martin G Miller (mgmiller) wrote : | #6 |
Thank you for you quick response.
I undid the lpadmin command as you suggested and after tinkering with the turboprint driver, finally got it to print again. However, the prints still looked horrible. I then tested the printer with a windows machine and discovered I had a hardware problem that coincidentally happened just as I followed your instructions above. I have since resolved the hardware issue (dirty print heads) and redid all the commands as you gave them to me above. It now stays in the que for a 4x6 for 1 min. 12 seconds, instead of 2 mins. 15 seconds. top shows gs shooting up to 99% cpu. It appears, the usb backend for cups is only part of the problem, there is still an issue with ghostscript. Under Feisty, this kind of print would stay in the que for no more than 5 seconds or so.
Martin G Miller (mgmiller) wrote : | #7 |
So are there any other thoughts on why ghostscript (gs) is using 99% of cpu resulting in slow photo printing?
Martin G Miller (mgmiller) wrote : | #8 |
There were many updates to cups today. All installed without incident. Printing, however still takes 65 seconds for a 4x6 color photoprint with gs using 99% cpu as indicated in top.
marsteegh (m-versteegh) wrote : | #9 |
same here ghostscript is slow as a dog, especially for .ps files containing large bitmaps. The problem is definitely in gs, and not in cups, since gv is also very slow and shows gs running on 99% cpu with ps -A
Martin G Miller (mgmiller) wrote : | #10 |
I was printing some 8 1/2 x 11 color photos today and they sat in the print que for 4 mins. 30 seconds before sending to the printer. This really is not very usable for prints this large. I have not made any changes to the system since changing the lpadmin command as noted above. I still have it set to lp0.
1) Did all the cups updates take care of the cups bug?
Should I change lpadmin back to the original way?
2) Is there any chance the ghostscript regression will be fixed?
Martin G Miller (mgmiller) wrote : | #11 |
I forgot to mention, top still says gs is using 98-99% cpu while this is happening.
Martin G Miller (mgmiller) wrote : | #12 |
Installed several updates to ghostscript today to fix encrypted pdf printing bug. They had no effect on the bug reported in this post and printing a 4x6 color photo still pauses for 65 seconds in print que with top showing gs using 99% cpu.
This bug is still open and not resolved.
glepore70 (greg-rhobard) wrote : | #13 |
Confirming this bug (or #159389) on 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux
Epson PictureMate takes over 15 minutes to print a single 4x6 photo. htop shows lp and gs taking all of both cores of my Athlon dual core 4200+, plus a gig of RAM, plus all my swap.
Martin G Miller (mgmiller) wrote : | #14 |
After all the updates to cups and ghostscript, I wanted to try returning the system to its original configuration and time it. So, undoing the change to cupsd.conf and resetting all the drivers back the way they were resulted in top showing 49% cpu for gs and 49% cpu for cups and having a 4x6 photo print remain in print que for 2mins. 45 seconds. Redoing the "cups patch" as above got rid of the cups cpu hit, but as before, gs spikes to 98-99% cpu and it sits in the que for 72 seconds. It is slowly getting worse. This ghostscript bug has not been resolved. Also, the cups problem remains, but at least there is a work around. As before, plain paper documents print almost instantly, it is only photo printing that is affected. Could Till Kamppeter please shed some light on whether anything is being done about these regressions? Will they be fixed in Hardy?
Skeletonix (tomaskloucek) wrote : | #15 |
in Hardy is it still same :(
Martin G Miller (mgmiller) wrote : | #16 |
Since upgrading to Hardy, the cups issue is resolved. I have all the cups settings back to system defaults and there is no mention of it in top during photo printing. Unfortunately, gs still spikes to 88+% and 4x6 photo prints sit in que for 85 seconds. The ghostscript bug is still open.
FriedChicken (domlyons) wrote : | #17 |
Confirmed.
Testing conditions: Gwenview Printing Assistant, printing a 4 MP photo, output 15x11,5 cm (~6x4 inches)
gs took between 1 minute and 1,5 minutes. I don't know really if this is a long time but I guess it is.
Changed in ghostscript: | |
status: | New → Confirmed |
mattcasters (matt-casters) wrote : | #18 |
This one and a half minute figure is also something I'm experiencing in Hardy. (and before in Gutsy as well)
You can multiply that time by the number of pictures you're putting on one page, regardless of their size.
For example, if you print 8 photos on a single page, it takes > 10 minutes.
3 pages with 8 photos takes > 40 minutes, etc.
For a beefy dual core with 3GB or RAM and otherwise unused, this seems to expose a serious problem in gs.
Martin G Miller (mgmiller) wrote : | #19 |
Mattcasters, I tried opening a bug at ghostscript, but after a brief go around with them, they decided it was just my system, so they closed it. If you add your experience, maybe they can figure out what's going on. Here is the link. http://
marsteegh (m-versteegh) wrote : | #20 |
I think it doesn't happen with upstream ghostscript. I seem to remember installing a compiled-
disclaimer: It has been a while and I cannot remember if I installed AFPL or GPL ghostscript. I might be the bug is in the GPL version but not the AFPL version. Th AFPL version is fast, that's for sure.
Craig (candrews-integralblue) wrote : | #21 |
I'm having the same problem (gs going to 100% and taking a long time) - perhaps this is the same issue as https:/
kede (kede) wrote : | #22 |
I have the same problem.
Printers:
- HP Laserjet 1200 CUPS+Gutenprint v5.2.3 attached by usb
- Epson Stylus Color 760 CUPS+Gutenprint v5.2.3 attached by usb
- Brother HL-5140 Foomatic/hl1250 attached by lpr (network)
This was on intrepit and now jaunty. The "server" has 1,2GB Ram and 1.4Ghz.
Configuration of cups was done using the web-interface.
When printing from Windows XP using samba, pages come out at once.
Wgen printing from Ubuntu Jaunty, it takes very long (1-30 minutes, depending on the document).
A single page from a PDF may take 1-2 Minutes, while 6 PDF-Pages containing scanned pictures take very long.
All documents are gray oder black/white.
Status says "processing".
"gs" takes 100% cpu for a while. After that the system seems to be idle and the printer-led flashes.
Printing starts minutes later whereby the printer only prints one page, stops, prints the next and so on.
It apears as if there is much data transferes to the printer? The original documents are not large (from 400kb to 5 Mb).
This problem makes printing almost impossible because you may have to wait half an hour to get your printout...
Martin G Miller (mgmiller) wrote : | #23 |
Since updating to the ghostscript package: 8.63.dfsg.
kede (kede) wrote : | #24 |
hm... normal documents (odt, text, etc) print instantly (2 seconds).
The cups test page starts after 8 seconds and the job has a size of 17k.
I noticed that printing a 7,5MB PDF (10 pages with scannend pages, no color) generates a 53MB job which of course takes time to process. This might be a problem of the client or application.
On the server, cups takes load for a short time, then gs, pdftops, sed, pstops in turn.
jonj (jonjackson) wrote : | #25 |
Appears to still be a problem for me on Jaunty, with ghostscript 8.64.dfsg.
Tom Chiverton (bugs-launchpad-net-falkensweb) wrote : | #26 |
- scotch_coldspring_talk.pdf Edit (252.1 KiB, application/pdf)
Same here in Jaunty using Okular, printing to a Fedora-hosted CUPS server which has a USB printer.
Try to print the attached grinds for ~30minutes, with 'gs' at the top of 'top'. The CUPS printers page for the local machine (not the server) i.e. http://
Used to be fine under earlier Ubuntu's, though I can't test with this exact PDF.
Martin G Miller (mgmiller) wrote : | #27 |
If you are using turboprint, there is a new version, 2.10-1 that addresses some specific issues with Jaunty. You may want to update your turboprint driver. I have had no problems at all with turboprint and a canon i960 after upgrading to Jaunty and the newest turboprint driver.
Tom Chiverton (bugs-launchpad-net-falkensweb) wrote : | #28 |
It's not a free upgrade from Turboprint 1.x to 2.x. I'll probably try the non-turboprint driver for my Canon PIxma iP4200 first.
Arne Brix (torpak) wrote : | #29 |
I have the same problem with jaunty. (very slow photo printing)
could this be related?
http://
Till Kamppeter (till-kamppeter) wrote : | #30 |
Arne Brix, do you have all updates applied to Jaunty, so that the fix of the problem you cite is present on your system? If not, please update now. Or did you update and this turned formerly fast photo printing to be too slow now?
Arne Brix (torpak) wrote : Re: [Bug 157044] Re: slow photo printing since upgrading Feisty to Gutsy | #31 |
Hello Till,
thank you for your lightning fast reply :-)
The Printer is a kyocera FS-C5100DN and used the ppd for linux
downloaded from the kyocera homepage.
Printing was fine using intrepid until some update broke it. (it's not
my computer that's affected, so i can not say which one it was exactly)
I tryed updating to the latest intrepid version, which didn't help.
I tryed updating to Jaunty (when it was final), which didn't help either.
I tryed updating again today (even activating proposed updates) which
didn't help.
I tryed using a different driver which displayed the same symptoms:
photos taking up to 20 minutes to print.
I print over network since the printer is in a different room but that
can't be the problem since it works fine under Windows.
If there is something i can do to diagnose the problem, please tell me.
I know close to nothing about cups and printing, but i have reasonable
experience with debian and ubuntu and know my way around the shell.
Greetings
Arne
-------
This message was sent using IMP, the Internet Messaging Program.
soyka (stefan-soyka) wrote : | #32 |
Hi all, I can not tell, if my problem is related or a new one. The PC I use has a 2,4 Ghz AMD CPU and 512 MB of memory. The printer is a Canon S520, attached to a mini-printserver over LAN. All windows PCs in the network are printing like a charm, unlike the Ubuntu Karmic PC (above), that takes very long time to print pictures (b&w A4, for instance) or OO documents (haven't seen it printing an image yet in fact).
Since I am sharing this unpleasant experience with one of my children and have to print his homework on a windows machine, the pressure on me is really high to get this fixed.
Yuriy Padlyak (gneeot) wrote : | #33 |
PDF printing in Lucud is too slow. 15 page document stays in printing queue too long, pages are being printed with huge pauses. Probably it is "gs" process, which does some processing.
Tom Chiverton (bugs-launchpad-net-falkensweb) wrote : | #34 |
It's hard to tell what you mean by 'too sow'.
How long does it take ? is the document color or black and white ? Graphics or text ? At what resolution (dpi) ? What is your hardware spec. ?
Pascal De Vuyst (pascal-devuyst) wrote : | #35 |
Martin G Miller wrote:
> Since updating to the ghostscript package: 8.63.dfsg.
> printing problems that I had have resolved. So, for me at least, this bug is finally closed.
This bug report is being closed due to your last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https:/
For other people who still experience slow printing it is better to file a seperate bug report with a good description of the problem and as a minimum the apport-collect information as described here: https:/
Changed in ghostscript (Ubuntu): | |
status: | Confirmed → Fix Released |
Craig (cmartens23) wrote : | #36 |
my printer prints things from Ubuntu very small. What is the fix for this?
Thanks,
Craig
Changed in ghostscript (Ubuntu): | |
assignee: | nobody → Craig (cmartens23) |
Please do the following test:
- Edit /etc/cups/ cupsd.conf adding a line "FileDevice yes"
- Restart CUPS with "sudo /etc/init.d/cupsys restart"
- Modify your print queue with "lpadmin -p <name of your print queue> -E -v file:/dev/usblp0"
Try to print again. Is it faster now?