Print job stuck at "Rendering completed" status

[MaksVal]

Hi!
Thanks for your job.
Please, help me.
The cups were stuck after status: "Rendering completed". This is the rasbian on raspberry 3 b+ (Raspbian GNU/Linux 10 Linux octopi 5.10.52-v7+ #1441 SMP Tue Aug 3 18:10:09 BST 2021 armv7l GNU/Linux)
But your repo was perfect worked on my notebook with ubuntu x86_64.

D [25/Oct/2021:15:11:13 +0100] [Job 39] CAPT: rastertocapt: start job
D [25/Oct/2021:15:11:13 +0100] [Job 39] CAPT: send  A1 A1 04 00
D [25/Oct/2021:15:11:13 +0100] [Job 39] Read 4 bytes of print data...
D [25/Oct/2021:15:11:13 +0100] [Job 39] CUPS_SC_CMD_DRAIN_OUTPUT received from driver...
D [25/Oct/2021:15:11:13 +0100] [Job 39] Wrote 4 bytes of print data...
D [25/Oct/2021:15:11:13 +0100] [Job 39] CAPT: waiting for 6 bytes
D [25/Oct/2021:15:11:13 +0100] [Job 39] Read 6 bytes of back-channel data...
D [25/Oct/2021:15:11:13 +0100] [Job 39] CAPT: waiting for 50 bytes
D [25/Oct/2021:15:11:13 +0100] [Job 39] Read 50 bytes of back-channel data...
D [25/Oct/2021:15:11:13 +0100] [Job 39] CAPT: recv  A1 A1 38 00 00 0B 31 2A 01 01 F0 FF 40 00 04 00
D [25/Oct/2021:15:11:13 +0100] [Job 39] CAPT: 41 00 01 00 D0 02 00 00 6F 08 00 00 E4 0D 00 00
D [25/Oct/2021:15:11:13 +0100] [Job 39] CAPT: 00 00 00 00 FA 02 00 00 F6 04 00 00 28 3C 32 32
D [25/Oct/2021:15:11:13 +0100] [Job 39] CAPT: 58 02 58 02 15 03 02 00
D [25/Oct/2021:15:11:13 +0100] [Job 39] Rendering completed
D [25/Oct/2021:15:11:13 +0100] cupsdMarkDirty(---J-)
D [25/Oct/2021:15:11:13 +0100] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Printing jobs and dirty files"
D [25/Oct/2021:15:11:13 +0100] [Job 39] Set job-printer-state-message to "Rendering completed", current level=INFO
D [25/Oct/2021:15:11:13 +0100] cupsdMarkDirty(----S)
D [25/Oct/2021:15:11:13 +0100] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Printing jobs and dirty files"
D [25/Oct/2021:15:11:13 +0100] cupsdMarkDirty(----S)
D [25/Oct/2021:15:11:13 +0100] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Printing jobs and dirty files"
D [25/Oct/2021:15:11:13 +0100] [Notifier] state=3
D [25/Oct/2021:15:11:13 +0100] [Notifier] state=3
D [25/Oct/2021:15:11:13 +0100] [Notifier] state=3
D [25/Oct/2021:15:11:13 +0100] [Notifier] state=3
D [25/Oct/2021:15:11:13 +0100] [Notifier] state=3
D [25/Oct/2021:15:11:13 +0100] [Notifier] state=3
D [25/Oct/2021:15:11:13 +0100] [Notifier] JobProgress
D [25/Oct/2021:15:11:13 +0100] [Notifier] state=3
D [25/Oct/2021:15:11:13 +0100] [Notifier] state=3
D [25/Oct/2021:15:11:13 +0100] [Notifier] state=3
D [25/Oct/2021:15:11:13 +0100] [Notifier] state=3
D [25/Oct/2021:15:11:13 +0100] [Notifier] state=3
D [25/Oct/2021:15:11:13 +0100] [Notifier] state=3
D [25/Oct/2021:15:11:13 +0100] [Notifier] state=3
D [25/Oct/2021:15:11:13 +0100] [Notifier] PrinterStateChanged
D [25/Oct/2021:15:11:13 +0100] [Notifier] state=3
D [25/Oct/2021:15:11:13 +0100] [Job 39] PID 1118 (/usr/lib/cups/filter/gstoraster) exited with no errors.
D [25/Oct/2021:15:11:14 +0100] [Job 39] CAPT: send  A0 E0 04 00
I [25/Oct/2021:15:11:14 +0100] Expiring subscriptions...
D [25/Oct/2021:15:11:14 +0100] [Job 39] Read 4 bytes of print data...
D [25/Oct/2021:15:11:14 +0100] [Job 39] CUPS_SC_CMD_DRAIN_OUTPUT received from driver...
D [25/Oct/2021:15:11:14 +0100] [Job 39] Wrote 4 bytes of print data...
D [25/Oct/2021:15:11:14 +0100] [Job 39] CAPT: waiting for 6 bytes
D [25/Oct/2021:15:11:14 +0100] [Job 39] Read 6 bytes of back-channel data...
D [25/Oct/2021:15:11:14 +0100] [Job 39] CAPT: recv  A0 E0 06 00 88 00
D [25/Oct/2021:15:11:14 +0100] [Job 39] CAPT: send  A2 A3 04 00
...

[alexpr]

Having the same problem. Does anybody know how to fix this? Thx!

[mounaiban]

Hi, and welcome to the Stuck Printer Club! Sorry for the late reply. The log I see here posted by @MaksVal has been cut off, but what was in the deleted part? Was it a lot of repeated back-and-forth CAPT: send A0 E0's and CAPT: recv A0 E0's leading nowhere?

If that was the case, it may be a limitation that we don't have a quick fix for. A similar problem has been discussed in agalakhov#7.

Long story short, captdriver requires far more "intimate" driver-device communications than CUPS is set up for. The job start sequence is more nuanced than those seen on PCL-like protocols, we can only start the job when the printer makes the right ready signal. The problem is that CUPS has not been returning the correct responses to CAPT status requests on some distros.

We use the CUPS back-channel reads (cups/backend.h/cupsBackChannelRead()) to poll the printer's status, but it works as we need to only on specific CUPS-libusb configurations. As a result, you can successfully print on some distros (Ubuntu, Fedora) and not others (Raspberry Pi OS/Raspbian).

CUPS was only really designed for use with PCL-like protocols that talk to the printer just to issue jobs and to request printer "status" reports. The "status" herein likely mean high-level things ink levels rather than the really deep stuff like status registers we're dealing with.

I am currently convinced that the only way to implement reliable printing on all operating systems is to create a new driver that talks to the printer directly, only using CUPS to manage jobs and queues. Official drivers use this approach, and printing this way is currently officially recommended. Most networked printers actually do this, but the "driver" is in the printer, not your RPi or PC.

References:

• Rendering completed - Stuck agalakhov/captdriver#7 (comment)
• ra1nst0rm3d@b93369a#commitcomment-45468739 (commit b93359a comment in a fork by @ra1nst0rm3d)
• https://www.cups.org/doc/api-filter.html#cupsSideChannelRead (Filter and Backend Programming. Apple CUPS Help) Note that the side channel API documentation is missing in the newer OpenPrinting versions

[CookieGMVN]

Hmmm so right now I can't print with my Raspberry Pi?

[mounaiban]

@CookieGMVN @alexpr You might still be able to print from a Raspberry Pi running Ubuntu. In a comment on an older commit (18797c4), someone reported success with printing from a Pi 3 running Ubuntu 19.10.1. I am expecting later versions to work too.

Please be aware that comments discussing causes of the driver failing to print on that commit are somewhat out of date at this point.

[sbn001]

Hmmm so right now I can't print with my Raspberry Pi?

There is some issue with Raspberry Pi OS with LBP2900 printer. I recommend installing Ubuntu Server to print to Canon LBP2900 printer using Raspberry Pi. It is working fine for me and one more user also confirmed it here. You can check my working configuration here as well.

[mofosyne]

Been trying to fight the LBP3000 for a week and am currently trying to document a working process for setting it up.

My current approach is to use a raspberry pi zero with raspbian lite and then compiling this driver to it... however am getting a similar error then this message. Idle - "CAPT: bad reply from printer, expected A2 E1 xx xx xx xx, got A0 E0 0C 00 00 8A"

So if I'm reading correctly, I should be using ubuntu server OS instead? I'll shall give that a shot.

If confirmed, then that should be a pretty critical information to add to the readme under for those who want a raspberry pi print server.

For now, if interested this is how I'm setting up my WIP print server:

My Current approach

Was using 'Raspbian GNU/Linux 11 (bullseye)' (lite version) on a raspberry pi zero

Setting up the environment in the print server

Details

#!/usr/bin/env bash
# Automated application of WiFi Print Server: From a Raspberry Pi Zero W to Windows 10/11 By brighterfusion from instructables
# This helper script was written by Brian Khuu on 2023 for https://www.instructables.com/WiFi-Print-Server-From-a-Raspberry-Pi-Zero-W-to-Wi/

# To run this shell script on gist (ref: https://gist.github.com/mob-sakai/174a32b95572e7d8fdbf8e6f43a528f6)
# Run this script via curl:
# bash <(curl -sL https://gist.githubusercontent.com/mofosyne/6baab7509ccd93f74d3fa225ea57d75d/raw/rpi_print_server_setup.bash)
# Run this script via wget:
# bash <(wget -o /dev/null -nv -O - https://gist.githubusercontent.com/mofosyne/6baab7509ccd93f74d3fa225ea57d75d/raw/rpi_print_server_setup.bash)

echo "Automated application of WiFi Print Server: From a Raspberry Pi Zero W to Windows 10/11 By brighterfusion from instructables"
echo "Assuming you have already done Step 1 of prepping and loading in the MicroSD card and loggin in here via ssh"

### Install Packages ###
echo "### Step 2: Initialize the RPi and Install Packages ###"

# Sync RPI system
sudo apt update -y && sudo apt upgrade -y

# Install
sudo apt install -y cups samba

# Install the CUPS print server and SAMBA file sharing packages. This will take a several additional minutes.
sudo usermod -a -G lpadmin $USER

### Config CUPS ###
echo "### Step 3: Config CUPS ###"

# Add an administrative user for the printer. Replace pi with your username
sudo usermod -a -G lpadmin $USER

# Enable web-based admin pages
sudo cupsctl --remote-any

# Restart CUPS
sudo systemctl restart cups

### Configure SAMBA ###
echo "### Step 4: Config SAMBA ###"

# now we want to edit `/etc/samba/smb.conf`
# * Under [printers]:
#     guest ok = yes
# * Under [print$]:
#     read only = no
SMBCONFPATCH=$(cat << EOF
--- smb.conf	2023-01-28 15:20:37.254209346 +1100
+++ editedsmb.conf	2023-01-28 15:36:54.867346266 +1100
@@ -215,7 +215,7 @@
    browseable = no
    path = /var/spool/samba
    printable = yes
-   guest ok = no
+   guest ok = yes
    read only = yes
    create mask = 0700
 
@@ -225,7 +225,7 @@
    comment = Printer Drivers
    path = /var/lib/samba/printers
    browseable = yes
-   read only = yes
+   read only = no
    guest ok = no
 # Uncomment to allow remote administration of Windows print drivers.
 # You may need to replace 'lpadmin' with the name of the group your
EOF
)

if ! echo "$SMBCONFPATCH" | sudo patch -R -p0 -s -f --dry-run /etc/samba/smb.conf; then
    echo "$SMBCONFPATCH" | sudo patch -p0 /etc/samba/smb.conf
else
    echo "/etc/samba/smb.conf already patched";
fi

# Restart Samba service.
sudo systemctl restart smbd

echo "Automated Portion Done..."
echo "Now you can proceed to Step 5: On CUPS Config Web Site..."

Compiling the LBP3000 driver

Details

#!/usr/bin/env bash
# LBP3000 CAPT driver on raspberry pi compile process
# Based on https://namvu.net/2021/07/setup-a-family-printer-with-a-raspberry-pi-1-and-canon-lbp-2900/
# But updated to use https://github.com/mounaiban/captdriver which is a more maintained fork

# Installing CUPS and the rest of the perquisites:
sudo apt install -y build-essential git autoconf libtool cups libcups2-dev libcupsimage2-dev

# Grab the source code:
git clone https://github.com/mounaiban/captdriver.git

# Compile the driver
pushd captdriver
autoreconf -i
./configure
make
make ppd
popd

# Install captdriver
#   The make install command above only copies the rastertocapt binary to the /usr/local/bin directory, 
#   while setting the necessary file ownerships and permissions. 
#   The cp command is still needed to place a copy of rastertocapt inside the CUPS filter directory.
pushd captdriver
sudo make install
popd

# Copy the files to their relevant locations
pushd captdriver
sudo cp src/rastertocapt /usr/lib/cups/filter/
sudo cp ppd/Canon*.ppd /usr/share/ppd/custom/
popd

The gist that I will update with the correct steps eventually...

https://gist.github.com/mofosyne/6baab7509ccd93f74d3fa225ea57d75d

=======

Update... looks like I got a raspberry pi zero V1 and ubuntu doesn't work on it... a raspberry pi zero V2 seems rather hard to get these days. GG

2nd Update... on a Ubuntu PC was able to confirm that I could run LBP3000. Ideally however I still would like to get all of this running on a raspberry pi zero V1. (Also cleaned up the LBP3000 compile bash script into https://gist.github.com/mofosyne/c84d23d863454478b4d192b9ca9afd5b in case anyone needs it)

[mounaiban]

Great work and respect @mofosyne for the build & installation script! (TIL about the shell commands pushd and popd, and nice profile pic)

I just want to say that this issue, along with its fellow issues agalakhov#7, agalakhov#36 and #14 have been suspected to involve bugs beyond the reach of captdriver. I do not expect this problem to be solvable from captdriver alone, but I would like to be proven wrong, as that would make life easier for all of us.

To summarise our findings as of time of writing:

The CUPS-libusb link is not quite suitable for intimate, full-time bi-directional communications to the standard required by CAPT devices. CUPS is known to replay past responses in a way that looks like symptom of overzealous read buffering. This has caused bad reply errors, or hanging at status checks due to crucial status flags not getting read properly by the backend.

When communicating with a CAPT device, no read buffering should be used, all responses must be fresh.

I am currently convinced that fixing this problem requires either:

1. Modifying CUPS to allow turning off that buffering behaviour, or
2. Creating a separate app that handles communications with CAPT devices with its own backend
   • this is the approach used by the official Canon drivers
   • if you have been using the official driver, you would have noticed ccpd on your system; this daemon receives print jobs from CUPS and passes print data to the CAPT devices (making use of captdrv and captmon).

(I'll update this post with links to notable comments related to this issue, we've got a quite a history at this point)