[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#931560: marked as done (cups-backend-bjnp: refuses to print with "out of paper" error)

Your message dated Thu, 15 Aug 2019 18:56:46 +0100
with message-id <15082019185053.a759c30adde4@desktop.copernicus.org.uk>
and subject line Re: Bug#931560: cups-backend-bjnp: refuses to print with "out of paper" error
has caused the Debian Bug report #931560,
regarding cups-backend-bjnp: refuses to print with "out of paper" error
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
931560: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931560
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: cups-backend-bjnp
Version: 2.0.1-1
Severity: important
Tags: upstream

Dear Maintainer,

Printer: Canon PIXMA MG6150
Backend: bjnp

Upgraded to Debian buster, cups now refuses to print with error
"Network host '...' is out of paper, will retry in 30 seconds..."

Tried restarting the printer, restarting cups, manually removing
'Reason' lines from /etc/cups/printers.conf (while cups is off),
nothing solved the issue.

I took a look at upstream changelog and noticed this for 2.0:
> Ink level reporting is added as well as improved error handling.

I suspected that there could be a regression, so I downgraded the
package (and only this package) to the version in stretch (1.2-2)
and the problem went away instantly. I didn't even need to restart
cups: the new bjnp backend started printing in the next automatic
retry. Tried upgrading again and problem returned; downgraded and
problem disappeared.

Note that I have a few ink cartdriges that are nearly running out,
but not low enough that the printer refuses to print. It could be
possible that the new ink level reporting code is misinterpreting
this condition as an "out of paper" condition. Unfortunately I
don't have new cartdriges at hand to test this hypothesis.

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.0.15-1-pve (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups-backend-bjnp depends on:
ii  libc6     2.28-10
ii  libcups2  2.2.10-6

Versions of packages cups-backend-bjnp recommends:
ii  printer-driver-gutenprint  5.3.1-7

cups-backend-bjnp suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message --- 
On Wed 14 Aug 2019 at 23:36:35 +0200, Louis Lagendijk wrote:

> hello,
> Upstream developer/maintainer here.
> Leonardo informed me of this bug, so I investigated the issue. It is
> indeed related to the ink level implementation, but I do NOT regard
> this as a bug.
> 
> Based on the logfile provided:
> 
> From the report in ReadData it has:
> CTK:M,IO,/,PBK,IO,/,GY,IO,/,BK,SET,/,C,IO,/,Y,LOW
> 
> So:
> M: Magenta IO (ink out)
> PBK: photo black: IO (ink out)
> BK: normal black SET (ok)
> C: Cyan: IO (ink out)
> Y: Yellow: LOW (low but can still print)
> 
> any IO (ink out) value indeed stops the printing. Now I understood that
> some(?) printers may continue to print under Windows as long as black
> (I assume BK or was it PBK) does not run out, but see below.
> 
> When you check the actual levels 
> 
> CIR:M=000,PBK=000,GY=000,BK=100,C=000,Y=010;
> 
> you will see that most cartridges were empty (M, PBK, C were at 0, only
> Y had some ink left. BK was 100% (values are in %), so continuing to
> print might be dangerous for the print head UNLESS the printer or the
> printer driver knows that it should not use the nozzles for those
> colors. You will still get a bad quality printout, probably B/W only if
> the printer can handle this on its own, without endangering the print
> head.
> 
> The windows driver apparently has a way to notify the user and ask for
> confirmation. It will quite likely avoid emitting any color info in the
> printout, hence there is no danger to the print head.
> 
> This avoiding color is something we cannot do within CUPS, as the
> backend receives an already rendered image. So I think that solving
> this is not desirable (it would be only a one line change, but I am
> really reluctant to change it as printing colors when the cartridge may
> damage the printhead).
> 
> Your bug report caused me to find one real bug though, whereby CUPS
> reports an out of paper instead of an out of ink. This will be solved
> in the 2.0.3 version, due out later this week

Thank you for your involvement, Louis, and thanks to Leonardo for
pushing his issue upstream. In the light of the first paragraph above
I am closing this report.

Cheers,

Brian.

--- End Message ---
Reply to: