Pharos Page Counts: Print Spooler vs. Device meters.

What if Pages Counts, Software & Meter Reads, don't match?

Why do counters or meter reads sometimes not match the print management software? Common question! Let's explore:

• USB ports are available on nearly all print devices and anyone with a laptop and a cable can plug in and print.

• Network cable can be unplugged and connected directly to a computer, bypassing management.

• Shared Windows Printers on a server that are not the Pharos managed queues will not be tracked.

• Direct printing, bypassing the Pharos print queues. This has many forms: LPR (515), port 9100, FTP, IPP, WebDAV, Apple (Bonjour), Novell and other services are running by default.

• Print from USB - Certain devices have a USB port on the front that allows printing. Pharos is able to capture this for certain devices, but it must be enabled.

• Native copy - On certain devices, there is a setting to capture copy data. This must be enabled or you will not track copies.

• Web printing using the embedded web pages on the printer to print.

• Cloud Printing portal - Some devices have the capability to print from cloud services like DropBox or OneDrive. These are currently not tracked.

• Service Prints - Any prints generated as a result of a service call may be counted in the meter reads. These would not show up in Pharos.

• Fax is usually not tracked at all in Pharos so any faxing that happens will contribute to click counts on the device and not in Pharos.

If all this is set correctly, you can typically expect that the Pharos counts should be within 4-5% of the meter reads or better. 

Scenarios that can cause print management software (PMS) numbers to not match hard counts or meter reads on devices:

Someone is bypassing the print management system and printing directly to the device. PMS would not record these, but obviously the device meters would.

User releases a job. The device jams. User clears the jam (the correct way). The device will reprint any pages that it is not 100% sure came out of the device correctly, so that results in a page or two (or maybe a little more) being reprinted. PMS does not know about these pages (and the user was already charged for the correct output anyway), so PMS does not log those reprints. The device meters would though.

User releases a job. The device jams. User clears the jam (the WRONG way, by powering off the device). This will flush the buffer of the device so the rest of the job is not printed. However, the user was already charged for what should have been the correct output anyway, so PMS logged the entire job, but the device meters would only log the pages that actually came out of the device.

User releases a job. The job is somehow corrupted in transit, or the user power cycles the machine after the first part of the job has arrived, but part of the job is still at the server. The device loses the formatting information, so it ends up printing many pages of garbage (you have likely seen this before. It is many pages with a few lines of printing on each. They generally stair step across the page near the top, and have odd characters like a heart, smiley face, empty box, ASCII characters, etc.). In this case, PMS would have counted (and billed for) the way the job *should* have printed. The device meters, however, would record each page of garbage.

User releases a job. The job is somehow corrupted in transit and the device dumps the entire job. PMS would have recorded what should have printed. The device meters will show nothing.

A job is sent with a bad, incompatible, etc. print driver. Depending on the details, PMS might record the correct number of pages, too few pages, or too many pages. What the device might do with this could vary dramatically, and therefore what it would record would also vary dramatically.

Blank pages and/or extraneous page breaks could exist in the job. PMS might be set to either count/charge for these or not count/charge for these. The device might also have a similar setting as to whether to print blanks pages or not. If the settings between these do not match, PMS might record the job one way and the device might count it another way. This would be device specific so it may or may not apply.

The device itself could be set to print multiple copies of a document. If this is the case, PMS would only be aware of the first copy of the document and would only account for that one copy. The device, of course, would count whatever was actually printed. This can happen when using a Fiery if the Fiery is allowed to hold the job and then re-release it after manipulating the document. This can also change attributes that might change the costing as well, so we recommend setting any Fierys to be set up as a pass through only and not allow holding the job for manipulation, reprint, etc.

If the device is not configured correctly to track copies. If the PMS is not setup properly to record copies, it will not record them, but the meter read will.

The device is configured to count pages with less than x% of color saturation as being mono. Pharos counts a job with any amount of color, when sent to a color capable machine, as being color.

Device is configured incorrectly as a 'Color' device in Uniprint, but the device is actually 'Mono'. If a color document is sent to that device, it will be counted as color.

Large print jobs restarting at the beginning when the printer runs out of paper? It's a recovery setting on certain manufacturers devices, duplex jobs will usually do this.*Please see the attached PDF.