Yea at the moment this project only works for local printers (as you understand, networkprinters on remote sites also counts as local) :)
I'm actually heading for usage tracking and report errors on the fly.
Cool. Now for the errors, are you looking for communication errors (getting the job there), machine errors (printer out of something /jammed), or both?
Originally my plan was to just follow the communication errors from the PC (client) to the printer, once there the printer is a whole nother story, but when you mention it i could probably get that up on my todo list, getting the printer errors as well.
These days (with direct IP printing so common/cheap) print servers seem to only get used for user usage tracking scenario. However most of the (driver/spool interrogation level) ones I've tested have great difficulty tracking duplexed pages, multiple copies, and the larger paper sizes (like 11x17) that can make a big difference when calculating someones actual usage.
Then there are the printers that locally store the by user usage tracking info... Which is great if you want to pole for it constantly to avoid missing something (not recommended) because they dump the logs when restarted.
Only thing I found that will guarantee-ably accurately catch everything sent to a printer is Capella Megatrack. Which is an accessory firmware add-on that sits on the printer and reports back to a SQL db. At the time I had investigated the options available, including a scratch write ... but decided the best thing for the company was to recommend the client go with Capella (which ain't cheap). The deployment has been running just fine for the last (almost) 5 years.
Please understand, I'm not trying to talk you out of the project. I really and truly hope you succeed ... I'm just sharing the fact that I couldn't quite pull it off.
I understand, no worries :) i find it better to know what i'm getting myself into but i myself always live by the motto "you can do anything, don't let nobody tell you otherwise, nothing is impossible" and i firmly beleave that there's no problem that can't be solved, the only question is who will come up with the answer :)
I'm looking in to the direct IP (TCP) printing as we speek, mainly this idiotic function:
"Output is transmitted directly to the printer without staging or respooling, saving system resources and enhancing print routing performance."
Sure it's a performance saver perhaps, but for a sys admin not in charge of the "pre-spool" server (Streamserve) it's really hard to debug anything cause the document that you print is just that, a TCP connection and nothing else, there's no spooled documents and no indication of what's getting printed. Love that the feature excists but there has to be more info in this area :)
Atm I've bumped into some problems regarding the network printers, seems like they don't spool documents as they should when they come from a second "printer" server running a software called "Streamserve" :/
I'm not familiar with that one, but I have seen some Novell print servers that would convert the print job on-the-fly from RAW/9100 (what you'd expect) to LPR/LPD 515 ... Which strangely was the root cause for many rather interesting failures. Like a 500 page job that kept reprinting the first 150 pages in a loop until the machine ran out of paper.
Hehe, i'm glad that we don't have novell here at all, we purged that system years ago.
Altho now we're left with Windows default things which is nice cause i can run API against them all but as mentioned, windows ain't to keen on spitting out logs or debug info.
Yours is more of a scanner then a job-information tool o guess even if yours had a few information features such as printer toner levels etc. Have you developed yours entirely from scratch cause it looks like you were surprised that "web access" was in your feature list? :P
What's it written in? C# or .NET?
Yes, Page Countster's primary function is to find and list all of the printers on a network and collect page count and tracking information for billing purposes. I'm not sure what you're referring to regarding the "surprised that "web access" was in your feature list" part. But if you can link me to the statement I'll have a better chance of answering.
1min 41sec into the video:
"i did wanna show you one thing tho that suprised me quite a bit, which was that i didn't even realize that my printer could be accessed and configured through the web" (think it's you in the video? or is that mauser?).
At any rate, yes it was a from scratch project, that occupied a great deal of my time for about 3 years. It is written in pure Win32 API C++ (no .NET/MFC/run-time requirement nonsense) using MSVS2005.
Cool, havn't been here long enough perhaps but i havn't seen many projects that doesn't
involve PHP or "simple" programming, not yet at least, except yours.
Gotta hand it to you for making such a in-depth project with packet forging/managing etc :)