Rendering completed - Stuck #7
Comments
|
I have the same problem. |
|
First of all thanks for this driver. Its for the first time i was able to setup Google Cloud Print. I'm using Canon-LBP-2900B on my Raspberry Pi running Raspbian Jessie 8. But I'm facing a strange issue, as people have mentioned above. In my case, I'm able to print only once. After i see the "Rendering Complete", further print jobs just dont print, they go from "Processing page 1..." to "Rendering Complete", but printing does not happen. I have to turn off and on the printer again, to fire one more print job, and it becomes useless again. Request you to please fix this issue. |
|
Hi, I do not own the printer anymore. Hopefully one of the printer owners could do some debugging. |
|
Hi Galakhov Its great to hear back from you. I hope the owners will take a look at it.
|
|
Hi is-cs, The message "Rendering Completed" is by CUPS. Keep in mind captdriver is a CUPS filter so it is launched and handle by CUPS. |
|
Hi @is-cs , How did you manage to run LBP2900 on your Raspberry Pi? I used this guide to install the driver on my Cubieboard 2 with Debian 9, but the printer didn't work at all showing the message "Rendering completed". No manipulations with my printer or driver lead to printing a single page. Did you do anything that is not in the guide above (added compiler options etc)? |
Don't sweat it, not even Canon has gotten it 100%. The proprietary driver froze frequently (like once out of four jobs) when I was using it on macOS 10.12, and I had to restart or reconnect the printer (LBP 3000) to keep printing. Anyone who manages to solve this problem would have outdone the boss. |
|
I just found this today on the CUPS repo: apple/cups#5310 Long story short, someone had the same problem with an HP printer, and found that disabling I have repeated the same workaround with my LBP3000, and now it takes on job after job without the need to restart or reconnect the printer. This is what you do: First, identify the vendor-product id of your printer with I would then add the following two lines to Remember to Save your edits, and restart or reconnect your printer. The printer should take on additional print jobs without needing more restarts! 😎 I have personally tested this with great success on Xubuntu 18.04.1 (CUPS 2.2.7) and CentOS 8.1.1911 (CUPS 2.2.6) [*2]. As far as my needs are concerned, I think at this point I am getting an experience that rivals or even exceeds what I got out of macOS. Honestly, I haven't got a clue why it worked for me, but I had to try this trick because it sounded like it would work.
|
|
Could we have this issue closed now? After some more testing, I think the problem has been largely fixed in 94b2bf2 for LBP2900, or my edit 1106978 for LBP3000. If anyone is using these versions or later, please respond to confirm with your printer model if your printer works (also, please ignore my message above and leave the no-reattach USB quirk off). @Goshik92: if you follow the instructions on https://brain.cdauth.eu/2014/01/16/canon-lbp2900-printer-on-linux/ you might get an error if you compiled captdriver as a normal user. You should see error messages in This is because CUPS only runs filters that are owned by |
|
Just pulled latest captdriver yesterday to make my LBP2900 work. Same issue, one job printed. I have set no-reattach thing up, not yet tested. |
Which Linux system / arch are you using? I could get my LPB2900 printer to print multiple pages repeatedly without problems on my Raspberry Pi 3 running Ubuntu server (19.10.1 armhf) and CUPS 2.2.12. I tried with the latest commit b2948ba from @mounaiban and it worked without requiring to restart the printer or adding anything to org.cups.usb-quirks. However, I could not get the same thing to work on a Pi running Raspbian. I am still unable to identify why it did not work in Raspbian. The macs on my home network can now print to LBP2900 via the CUPS running on the Pi (Ubuntu) but I have not been able print from my Windows devices yet. There might be some other issues with communication between CUPS and the Windows system. Please try compiling the captdriver from https://github.com/mounaiban/captdriver and check if it can print more than once. |
|
I am running Manjaro on x86_64. Thank you for the link, i'll give it a try and report my progress. |
|
Hi, I have a LBP2900 printer. Have it connected to a rpi 3a+. Installed Raspbian lite today (Raspbian GNU/Linux 10), installed CUPS 2.2.10. Tried install both agalakhov and mounaiban capt driver, also tried editing /usr/share/cups/usb/org.cups.usb-quirks, restarting printer, pause/resume all ended up with same result, "Rendering completed" and nothing printed. I tried to enable error logging via cupsctl --debug-logging and looked at /var/log/cups/error_log D [25/Jun/2020:19:00:02 +0100] [CGI] cgiSetArray: job_printer_name[0]="Canon_LBP2900" After that I had a lot of repeated messages (identical as below) I [25/Jun/2020:19:00:07 +0100] Expiring subscriptions... I also checked dmesg | grep usblp So it turns out the /dev/usb/lp0 appears for a very short time and then gets removed again. Now trying to print again moves past the "Rendering completed", but halts with a new error. lpstat -p From /var/log/cups/error_log D [25/Jun/2020:20:43:20 +0100] [Job 12] CAPT: rastertocapt: start job After this the /dev/usb/lp0 got removed again [ 1263.347568] usblp 1-1:1.0: usblp0: USB Bidirectional printer dev 6 if 0 alt 0 proto 2 vid 0x04A9 pid 0x2676 And restarting the print job gets stuck at "Rendering completed". |
|
@fresun78 thanks for your feedback. Try reverting to 216fddb with Please note that printing support was a lot less complete at the time of the commit; while it was the last commit known to work on Raspbian with the LBP2900, at that stage you had to restart the printer between jobs (among other limitations). At time of writing, I believe this issue is due to a failure to correctly communicate with the LBP2900 to obtain a job number (see I suspect that the In the meantime, I am thinking of overriding the job number with the one provided by CUPS. This is a return to how things were done in 216fddb, except that the job number will be allowed to move beyond |
|
@mounaiban You're right, I did a checkout of 216fddb and it is working (1 print job). I haven't had time to test too much, just printed one test page and it was working without any problems. What is the print job no. used for? I read your comment in the other issue tracker, that the filter gets reset for every print job. I suppose for a persistent tracking and assigning of self-generated print job no. some IPC with a background process or just writing to a text file would be possible solutions? The best I suppose would be to find out how LBP2900 actually communicates and sends job no. The (reverse-engineered) communication protocol is working for other LBP printers but not LBP2900? |
|
I did the original reverse-engineering with LBP2900. It worked but was quite incomplete. Then others continued it with other models. It could be that LBP2900 had some bug that was fixed in later models and that it needs some unknown workaround. I did not manage to restore the printer's original state after printing. Unfortunately I don't own any LBP printers anymore so I can't help further. |
|
@fresun78: Just realised that job numbers generated by CUPS are easy to read. Recall that there are six arguments sent to a filter, and the first argument is the job ID, so I might just shove The job number is an identifier that must be assigned to every job received by the printer. I think the printer uses it to tell when the last job ends and the next one begins. Every next job will need a different number for the printer. While I feel that those numbers are not quite needed for personal printers like the LBP2900 and 3000, those may be useful on network-capable, multi-user printers like the LBP6300dn. I am trying to understand the relationship between the three or so status check commands @agalakhov discovered for the LBP2900. Based on Wireshark studies I have done so far, I am suspecting that the printer cannot read and write the status registers at the same time, so reading the extended status too much (which |
|
@mounaiban @agalakhov Thanks a lot for the work! I was not expecting that anybody was still working on this. Where is the fun in just buying something new and dump this otherwise perfectly working printer? |
|
Hi again, I have pushed a new branch @nerk I love Canon printers. They're engineering masterpieces that have fallen victim to some very poor decisions regarding the software architecture on those fine machines. Canon needed HP to do its mechanisms justice with superior firmware and drivers. |
|
BTW, many HP printers are mechanically identical to HP ones. But HP does not have any software problems. |
|
@mounaiban I tried your new branch on 32-bit Raspberry PI OS (Raspbian) on my Pi 4 and the problem is still the same, unfortunately. I also noticed that after the first print job, lpinfo -v no longer show the Canon printer URI. I have to pull and reconnect the USB cable to make it appear again. |
|
@nerk Did you manage to print some pages, or did the printer freeze before the first page? At any rate, this looks like the end of the road for my hacks... 🤔 We will have to look much deeper to get the printers to work properly under Raspbian. |
|
@mounaiban Thanks for your work. Don't sweat it. Maybe, I'll try to investigate and debug the code - one day. I don't think I am smart enough, though. It has always been PITA to get this printer running under Linux, even with the official CANON drivers. They are no longer compatible with recent versions of CUPS either. I actually tried all the different ways I found on the Web to get this printer running on 64-bit Linux and recent Linux versions, but without any luck. In the end, I resorted in installing Ubuntu 14.04 and the official CAPT drivers in a LXC container, running as a guest on my desktop machine. I documented the process in case anybody needs it. It proved to be a pretty reliable setup. Having everything on the Pi would be much nicer, of course. |
|
@mounaiban To answer your actual question: The printer froze before the first page. One thing I might try is to use the version on your branch on my 20.04 Ubuntu machine and compare the data sent over USB with the Raspi. Maybe it's a byte ordering problem. |
|
@sbn001 If you still cannot print from Windows, maybe the solution is to use a particular Windows driver. Have a look at the end of https://github.com/nerk/canon-capt-installation. |
Thank you for the information. I could successfully print from Windows 10 devices after installing Bonjour Print Services from Apple. Windows recognized the printer shared from CUPS and worked independent of the driver. More on that available in this discussion. The official drivers from Canon works well on Intel x86 systems (both 32 bit and 64 bit). The only problem is with the ARM devices which are not officially supported by Canon. |
|
Hello again, and Merry Christmas! 🎄 🎅 Here's a closer look at your logs: The driver is seen here requesting Meanwhile, this came up pretty often in the logs: Inferring from the previous example, CUPS might be stuck replaying the first See also:
|
|
Hello and Happy New Year! Thank you for your great work! I tried to run lbp300 on Raspbian (debian 10) for rpi4. Unfortunately, both agalakhov/captdriver and 0.1.4-dev-use-cups-job-id do not work (no pages are printed). Cups stuck at "Rendering completed". Message "CAPT: bad reply from printer, expected A0 E0 xx xx xx xx, got" appears when I switch off the printer and this message does not disappear when I switch on the printer Adding "no-reattach" to org.cups.usb-quirks does not help. When try to print a test page I get
After 5 minutes of waiting, when I switch the printer off I get
Switching the printer on does not add anything to error_log I'm really interesting in helping with the driver testing/coding, if it possible. |
|
@mmlion Hi, and welcome to the Stuck Printer Club! I wish I had a solution for this right now, but it is going to be a while before some progress is made on this front. I am currently trying to figure out a way to work around the response replay problem on the LBP3000 using libusb directly, after failing to find a way using CUPS' limited backend commands. Maybe try building newer versions of libusb (1.0.23 or later) and CUPS from source? |
|
I've tried libusb-1.0-0_1.0.24-2_armhf from debian 11 with no luck (no-reattach also did not help). CUPS seems to be much harder to install (due to a lot of dependencies). Do you think it can help? If yes, I may try just debian 11 to try CUPS 2.3.3 ... |
|
If a newer version of libusb doesn't work with the same version of CUPS, this implicates CUPS as the source of the problem, specifically the way CUPS handles communications with the devices. There are two (untested) workarounds I can think about at the moment for 10.6:
@nerk had mentioned earlier in this issue that there could be a "byte ordering problem". I have also been wanting to investigate this, It would involve using Wireshark to capture commands sent to the printer on three different configurations: i. Captdriver on systems where it doesn't print (e.g. Raspbian, ZorinOS 32-bit) The results would then be compared to see if bytes have been swapped on the outgoing commands. I really hope this isn't the case, because if it was, the workaround could be messy... 😱 |
|
Byte swaps are very unlikely. Likely is that CUPS has somehow broken back channel. AFAIK the only driver really relying on this channel is our one. If, for instance, the back channel is buffered (that is, data come in large chunks and are delayed until the chunk is full), we'll get a stuck printer. If CUPS silently introduced such kind of buffering (maybe even by mistake), no one but us will complain. Official driver completely replaces a large part of CUPS and thus does not depend on back channel functionality. |
|
So I've made cups 2.3.3 from source and try it with capt-driver (previously built for cups 2.3.1). Two times actually, and the result was slightly different (I'm not sure why). First attempt: cups was unable to add the printer with the following in systemlog Second attempt (after I removed all cups packages clear all cups deb packages and reinstall them): cups was also unable to add the printer but gave no errors. Also lpadmin gave me "success", but the printer does not appear. I think the reason is the following. I've tried to recompile captdriver with cups 2.3.3 installed, but gcc gave It seems very strange, since file /usr/include/cups/raster.h (on my rpi) does have these functions defined... May be I did something wrong? |
|
|
|
@mounaiban @agalakhov Byte swapping problem was just a wild guess. However, wasn't somebody sucessfully running the driver under Ubuntu on a Raspi? That would rule out byte ordering as the reason. |
|
@agalakhov Yes, this helps, thanks. rastertocapt compiles without problems, but still cups 2.3.3 was unable to add the printer. cupsd felt down every time after lpadmin -p. Here are logs: /var/log/cups/error_log was empty
@agalakhov @mounaiban @nerk Is it worth to try ubuntu on rpi instead of debian 10? 20.10 has cups 2.3.3... |
|
Most RPi distributions have the same little-endian byte ordering as x86. The driver itself was developed with byte-order in mind so byte-order problems are extremely unlikely. I never cast words to bytes in the driver. |
|
@mmlion This is "Segmentation fault" in CUPS (signal 11). Should never happen and does not depend on the driver. This is a CUPS bug. |
|
Hello, I had been doing some testing with printing on the LBP 2900 printer from Raspbian. While testing the printer could not print normally and got stuck in ' Processing - "Rendering completed" ' message. It could not print even after restart the printer or unplugging and re-plugging the USB cable and pressing "Release Job" in the CUPS remote web interface. In the processing of testing, I discovered that the LBP 2900 printed the stuck print job after undertaking following steps:
The printer was able to print a single page next time as well by following the above process again. I think that printing with captdriver is stuck because the printer (or the driver) is expecting some response / reply which has not been met by the driver. The stuck printer seems to be refreshed after printing from Windows or some other capable device and once I connected the printer back to the Raspberry PI, it printed without errors and got stuck again. I tried printing with the current master (commit: f2077b6 version: 0.1.3) and also from the fork maintained by @mounaiban (commit: 5cefa27 version: 0.1.4-m5) but got similar results. I don't know if this information would be useful in resolving the issue. I can share the cups error logs if those can be helpful. I will also continue testing by upgrading the My current configuration is as shown below: |
I have been printing wirelessly from my Windows, Mac, Android and iOS devices to the Canon LBP2900 printer for some time now, using a Raspberry Pi 3B running Ubuntu 20.04.2 LTS. It has been working (almost) flawlessly in printing multiple pages, multiple times from different devices without getting stuck. @mmlion I think it would be sensible to install Ubuntu Server (https://ubuntu.com/download/raspberry-pi) on a Raspberry Pi, until the Raspbian issue gets solved, to print wirelessly to your old Canon printer. I am sharing my current working configuration below: |
|
I have also been having a similar issue when printing through CUPS with my MP240 on Arch Linux x86_64 for a few months, previously (since 2015 and until today) I was using the official Canon driver, which had the exact same getting-stuck-after-printing-right-up-until-the-end problems so I tried switching to the open-source counterpart today, so that's why I suspect that this is a somewhat recent USB/ Printing on Windows 8 through the official drivers using the same setup worked fine, and the first page printed on Linux after rebooting from printing on Windows seemed to also work and finish correctly, I believe. In my case if I wait for around 15 minutes the printer finishes correctly, it just gets stuck in place 3/4 into the page for entire minutes, moving the printing head a bit from time to time. If I disconnect the USB connection between the printer and the computer it stops and finishes. So, to me, it seems like the printer is waiting for some kind of USB response. I have tried @mounaiban's solution above and it seems like adding the quirk (with the proper VID/PID) via Adding Anyway, with this I can use my printer again, so thanks for all the information in this thread. I'll try to add the quirk officially. |
Without it the printer gets stuck waiting for some kind of USB response from the computer 3/4 into the page. Right at the end of the job. Sometimes it moves the printing head once every few minutes, if we wait for 20-30 minutes it often finishes correctly. Which is unacceptable. Using `no-reattach unidir` instead of only `unidir` seems to also work fine, but is seemed superfluous in my case, so try that if things are still wonky. Disconnecting the USB cable makes it stop the job instantly, spitting the rest of the page. The same setup works on Windows just fine. Maybe adding the other MP2XX models into the list should be considered. In my case, until a few months ago printing via CUPS without any kinds of quirks seemed to work fine, so it seems like some kind of regression. The credit goes to @mounaiban for the original solution: agalakhov/captdriver#7 (comment) More information here: agalakhov/captdriver#7 (comment)
Without it the printer gets stuck waiting for some kind of USB response from the computer 3/4 into the page. Right at the end of the job. Sometimes it moves the printing head once every few minutes, if we wait for 20-30 minutes it often finishes correctly. Which is unacceptable. Using `no-reattach unidir` instead of only `unidir` seems to also work fine, but is seemed superfluous in my case, so try that if things are still wonky. Disconnecting the USB cable makes it stop the job instantly, spitting the rest of the page. The same setup works on Windows just fine. Maybe adding the other MP2XX models into the list should be considered. In my case, until a few months ago printing via CUPS without any kinds of quirks seemed to work fine, so it seems like some kind of regression. The credit goes to @mounaiban for the original solution: agalakhov/captdriver#7 (comment) More information here: agalakhov/captdriver#7 (comment)
|
@Swyter Glad that you were able to solve an issue with a Canon inkjet using info in the issues section of a seemingly unrelated driver. 👼 On the other hand, I wish there was a means of flushing the backchannel buffer or a similar feature in CUPS that would solve this stuck printer issue with captdriver. I think it's highly unlikely that such a feature would be implemented though. Apple probably thinks we should rewrite our driver as a Printer Application and handle communications with the printer with libusb. |
|
@sbn001 Thanks for your suggestion to use Ubuntu Server OS on a Raspberry Pi. This repo(https://github.com/mounaiban/captdriver) worked for me. |
|
Just letting you all know, a fix for I have been able to print to an LBP3000 from ZorinOS Education 16.1 (x86_64) consistently, and I invite all of you to test it out, (especially on Raspbian/Raspberry Pi OS, and I hope it works for you. If you have recently updated or cloned my fork, please remember to use the |
|
@mounaiban Ooops, maybe I gave up too early because I finally dumped my old Canon printer a few weeks ago. I switched to a HP monochrome Laser printer, which is working out of the box without any pain. However, the mechanical build quality of the old Canon printer really seems to be superior. I wish everybody success in keeping the Canons working! |
|
Thanks @nerk for being with us anyway, I almost gave up on my printer too trying to find a fix for this issue. It didn't help that a shop in my city was, and still is, selling WiFi-capable monochrome printers for peanuts. I am beginning to actually like the CAPT protocol in a retrocomputing kind of way. The engineers at Canon have my respect for trying to implement a printer device that was supposed to have practically unlimited memory, despite how much of a mess it turned out. CAPT is a relic of a time when it was still a luxury to have a printer that had enough on-board memory and computing power to take on random PDFs and poorly-optimised Word documents in their entirety. |
|
Just tested my Canon LBP2900 with 0.1.4.1-RE branch from @mounaiban on Raspberry Pi OS (bullseye) but the issue is still the same. Tried adding as well but no sucsess in printing. The error log is as follows |
Hi i am a novice with linux commands. can you tell me the command to open and edit the file you mentioned above on mac terminal |
Sometimes, the printing get stuck with the message "Rendering completed". Sometimes it can be fixed by turning the printer off and on. Sometimes, it can be fixed by disabling the printer and enabling it. Often both of them has to be done sequentially to fix the issue.
Ubuntu 14.04
Canon LBP 2900B
The text was updated successfully, but these errors were encountered: