Bug 581825

+++ This bug was initially created as a clone of Bug #580604 +++

--- Additional comment from tao on 2010-04-08 11:47:02 EDT ---

Event posted on 2010-04-08 08:42 PDT by woodard

Description of problem:
Ink or toner levels are not reported until you first print a test page. The printer is quite capable of providing that information via snmp and possibly through other means. (I've done printers for years.)

Then when it displays the levels, the levels are wrong 

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
This event sent from IssueTracker by woodard  [LLNL (desktop)]
 issue 738883

--- Additional comment from woodard on 2010-04-08 11:48:00 EDT ---

Created an attachment (id=405338)
photo of printer's console

--- Additional comment from woodard on 2010-04-08 11:48:33 EDT ---

Created an attachment (id=405339)
from system-config-printer

--- Additional comment from twaugh on 2010-04-08 12:42:10 EDT ---

(In reply to comment #1)
> Description of problem:
> Ink or toner levels are not reported until you first print a test page.

This is sort of by design with CUPS.  The reporting of ink levels is in the backends, and the backends aren't run unless to process a job.

In future we could do it as part of the PostScript autoconfiguration which CUPS now supports.  I've filed that as bug #580634.

> The printer is quite capable of providing that information via snmp and possibly
> through other means. (I've done printers for years.)

CUPS uses the SNMP Printer MIB to obtain supply levels.

> Then when it displays the levels, the levels are wrong 

I'd like to see what the printer is actually reporting.

Please run 'cupsctl -U root LogLevel=debug2' to turn on verbose logging, clear out the error log file with 'su -c "/sbin/service cups restartlog"', then send a print job.

Afterwards you can turn off debug logging with 'cupsctl -U root --no-debug-logging'.

Please attach the /var/log/cups/error_log file.

--- Additional comment from woodard on 2010-04-08 15:21:45 EDT ---

Created an attachment (id=405385)
the requested error log

two print jobs.

--- Additional comment from woodard on 2010-04-08 15:26:51 EDT ---

Also note on the mac the supply levels look pretty close to what is on the console. I don't know how they are getting their data. Back when I was working with printer mibs quite a lot, I found tons of errors in the implementations.

--- Additional comment from jpopelka on 2010-04-09 04:02:02 EDT ---

From the error_log:

d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.1 = 97
d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.2 = 53
d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.3 = 48
d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.4 = 62
D [08/Apr/2010:14:11:30 -0500] [Job 3] ATTR: marker-levels=15,24,24,31
D [08/Apr/2010:14:13:46 -0500] [Job 4] ATTR: marker-names="black ink C4906A","yellow ink C4909A","magenta ink C4908A","cyan ink C4907A"

--- Additional comment from twaugh on 2010-04-09 05:28:35 EDT ---

I think I can see what's going on -- the printer is filling in a percentage when it should be filling in a level.  Just to check, let's see what the prtMarkerSuppliesMaxCapacity values are:

snmpwalk -Os -c public -v1 192.168.1.100 1.3.6.1.2.1.43.11.1.1.8

(you may need to install net-snmp-utils for that)

--- Additional comment from twaugh on 2010-04-09 05:52:46 EDT ---

Here's how I got that long SNMP number: by digging through cups/backend/backend-private.h:

/*
 * OID constants...
 */

/* Host MIB */
#define CUPS_OID_mib2                           1,3,6,1,2,1
[...]
/* Printer MIB */
#define CUPS_OID_printmib                       CUPS_OID_mib2,43
[...]
#define CUPS_OID_prtMarkerSupplies              CUPS_OID_printmib,11
#define CUPS_OID_prtMarkerSuppliesTable         CUPS_OID_prtMarkerSupplies,1
#define CUPS_OID_prtMarkerSuppliesEntry         CUPS_OID_prtMarkerSuppliesTable,1
[...]
#define CUPS_OID_prtMarkerSuppliesMaxCapacity   CUPS_OID_prtMarkerSuppliesEntry,8
#define CUPS_OID_prtMarkerSuppliesLevel         CUPS_OID_prtMarkerSuppliesEntry,9

They are expressed with commas "," instead of "." in the header file because they are used to initialise arrays, like:

static const int        prtMarkerSuppliesEntry[] =
                        { CUPS_OID_prtMarkerSuppliesEntry, -1 };
                                        /* Supplies OID */

--- Additional comment from tao on 2010-04-12 12:45:15 EDT ---

Event posted on 2010-04-12 09:45 PDT by woodard

[ben@snog Desktop]$ snmpwalk -Os -c public -v1 192.168.1.100
1.3.6.1.2.1.43.11.1.1.8
mib-2.43.11.1.1.8.1.1 = INTEGER: 607
mib-2.43.11.1.1.8.1.2 = INTEGER: 220
mib-2.43.11.1.1.8.1.3 = INTEGER: 200
mib-2.43.11.1.1.8.1.4 = INTEGER: 200
[ben@snog Desktop]$ 



This event sent from IssueTracker by woodard 
 issue 738883

--- Additional comment from twaugh on 2010-04-12 12:54:09 EDT ---

Yes, the printer is filling in the wrong value in the levels fields.

d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.1 = 97

This is the black ink level.  It is saying it is at 97 units with a capacity of 607, so about 15%.

d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.2 = 53

Next, this is 53 units out of 220.

d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.3 = 48

48 out of 200.

d [08/Apr/2010:14:11:30 -0500] [Job 3] prtMarkerSuppliesLevel.1.4 = 62

62 out of 200.

D [08/Apr/2010:14:11:30 -0500] [Job 3] ATTR: marker-levels=15,24,24,31

So these percentages are correct.

The printer is reporting incorrect numbers.

--- Additional comment from woodard on 2010-04-12 15:48:06 EDT ---

Current installed firmware version:
Firmware Version   DLM1FN0924AR
matches the current firmware version on:
http://h10025.www1.hp.com/ewfrf/wc/softwareList?os=228&lc=en&dlc=en&cc=us&swfsequence=1&product=3752459〈=en

When I was working on printers all the time, this kind of thing was EXTREMELY common. You just need a quirk to work around it. Yeah, I know it is buggy but there is nothing else you can do. You stand on principle and you can report it to the vendor and maybe if you are lucky they might fix it. However, in my experience that almost never happens. The problem is that they spend all of their time and money on new product engineering and no time on current product engineering. Therefore, once it has been sold they rarely fix things.