socket backend pagecounting off by one

[John A. Murdie]

I've done some little tests of the SNMP page counting in the 1.4.4 socket backend with some HP printers (an HP Color LaserJet 5550dtn, for a start). When printing just one page, the difference between the start_count and the page_count - see CUPS 1.4.4 socket.c line 440:

if (have_supplies &&
      !backendSNMPSupplies(snmp_fd, &(addr->addr), &page_count, NULL) &&
      page_count > start_count)
    fprintf(stderr, "PAGE: total %d\n", page_count - start_count);

is zero, so the "PAGE: total ..." log line is never emitted. (Incidentally, I think that page counts of 0 should be recorded.)

In general, when printing N pages, N - 1 pages are (often?/always?) recorded. I think that the reason is that the HP printers take some time for the page count to stabilise. If I do place an experimental 'sleep(10)' just before the 'after' page_count SNMP code in socket.c, the page count is correct. Naturally, I wouldn't want to add a useless delay in the socket backend, but some of us do want reliable, actual, per-job page counts. I've found that even when these printers report themselves idle (hrPrinterStatus == CUPS_TC_idle) the page count is still not stable.

I will report this as a bug if requested. (The page-counting backend wrapper I've been using for years copes with this problem, but I think I should use native functionality if it is provided.)

Addendum:

I turned on SNMP page counting by correcting snmp.conf to have our printers' SNMP get community string:

Address @LOCAL
Community ********

and adding:

*cupsSNMPSupplies: True

to the end of the PPD file for the device in question.