topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • October 22, 2019, 02:58 PM
  • Proudly celebrating 13 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: [Python][Windows] Debug/Gather printer information  (Read 7174 times)

DoXiD

  • Participant
  • Joined in 2011
  • *
  • Posts: 5
    • View Profile
    • Donate to Member
[Python][Windows] Debug/Gather printer information
« on: April 21, 2011, 03:18 AM »
Hi!

first off, This application is intended as a tool to gather printer information quickly, not in-depth hard core debugging of bits and bytes.
Secondly, you will need Python for this to work, i will not compile this application cause it's constantly developed and changed.
Thirdly, i cannot be held responsible for anything this code does or be demanded to support it, i will release it as is and give out assistance here in meens of time for free.
(i know the code ain't perfect, and there's probably better tools for this, but this is a light-weight, fast and flexible way to debug information about the printer and it's documents)

The software is released under the original BSD Licens: http://www.openbsd.org/policy.html
The software also requires the library "pywin32": http://sourceforge.n...win32/files/pywin32/

(There are plans to evolve this software to actually dig into the printer and fetch information)

Code: Python [Select]
  1. __author__ = "Anton Hvornum"
  2. __copyright__ = "Copyright 2011, Anton Hvornum under the BSD License"
  3. __credits__ = ["Anton Hvornum"]
  4. __license__ = "BSD License (Original)"
  5. __version__ = "0.0.1"
  6. __maintainer__ = "Anton Hvornum"
  7. __email__ = "[email protected]"
  8. __status__ = "Alpha"
  9.  
  10. import win32print, os
  11.  
  12. wp = win32print
  13. printer_types = [(wp.PRINTER_ENUM_SHARED, 'shared'), (wp.PRINTER_ENUM_LOCAL, 'local'), (wp.PRINTER_ENUM_CONNECTIONS, 'network')]
  14.  
  15. print_directory = wp.GetPrintProcessorDirectory()
  16. if not 'printers' in print_directory:
  17.         print_directory = os.path.normpath(print_directory + '/../../PRINTERS')
  18.  
  19. def get_printer(name = '*'):
  20.         printer_list = {}
  21.         for printer_type in printer_types:
  22.                 print printer_type
  23.                 for printer in win32print.EnumPrinters(printer_type[0],None,1):
  24.                         if name == '*':
  25.                                 printer_list[printer] = win32print.OpenPrinter(printer[2])
  26.                         elif name.lower() in printer[2].lower():
  27.                                 printer_list[printer] = win32print.OpenPrinter(printer[2])
  28.         return printer_list
  29.  
  30. def GetJobList(printer):
  31.         printer_handle = win32print.OpenPrinter(printer)
  32.  
  33.         job_list = win32print.EnumJobs(printer_handle,0,-1,2)
  34.         win32print.ClosePrinter(printer_handle)
  35.  
  36.         return job_list
  37.  
  38. def getJobDetail(printer, id):
  39.         printer_handle = win32print.OpenPrinter(printer)
  40.  
  41.         job_detail = win32print.GetJob(printer_handle,id,2)
  42.         win32print.ClosePrinter(printer_handle)
  43.  
  44.         return job_detail
  45.  
  46. printer_list = get_printer(raw_input('Name of the printer you\'re looking for (blank or * for all): '))
  47.  
  48. for printer in printer_list:
  49.         print 'Joblist for:',printer
  50.         for job in GetJobList(printer[2]):
  51.                 if 'JobId' in job:
  52.                         job_detail = getJobDetail(printer[2], job['JobId'])
  53.                         if not 'file_path' in job_detail:
  54.                                 job_str = '00000'
  55.                                 job_str = job_str[:-len(str(job_detail['JobId']))] + str(job_detail['JobId'])
  56.  
  57.                                 shd_file = os.path.join(str(print_directory), job_str + '.SHD')
  58.                                 spl_file = os.path.join(str(print_directory), job_str + '.SPL')
  59.  
  60.                                 print shd_file
  61.                                 print spl_file
  62.  
  63.                                 if os.path.isfile(shd_file) and os.path.isfile(spl_file):
  64.                                         job_detail['file_path'] = os.path.join(str(print_directory), str(job_detail['JobId']))
  65.                                 else:
  66.                                         job_detail['file_path'] = str(print_directory)
  67.                         for key in job_detail:
  68.                                 print '\t', key, '::', job_detal[key]
  69.                 print ''

Stoic Joker

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 6,517
    • View Profile
    • Donate to Member
Re: [Python][Windows] Debug/Gather printer information
« Reply #1 on: April 21, 2011, 06:39 AM »
Interesting, I'll have to scare up a copy of python to play with this. I'm guessing from just looking at the code that it's for gathering printer info from local machine only, yes? Are you heading towards something that does usage tracking by user?

Not sure if you've seen this (Page Countster), but I'm also working on a printer management project. Although not actively at the moment as the project is back burnered.

DoXiD

  • Participant
  • Joined in 2011
  • *
  • Posts: 5
    • View Profile
    • Donate to Member
Re: [Python][Windows] Debug/Gather printer information
« Reply #2 on: April 26, 2011, 02:26 AM »
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.
This is mostly developed due to the lack of information given by windows when customers call in and say that their printouts never show up in the printer, this way i can track where, why and when :)

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" :/



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 suprised that "web access" was in your feature list? :P

What's it written in? C# or .NET?

Stoic Joker

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 6,517
    • View Profile
    • Donate to Member
Re: [Python][Windows] Debug/Gather printer information
« Reply #3 on: April 26, 2011, 07:38 AM »
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?

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.

This is mostly developed due to the lack of information given by windows when customers call in and say that their printouts never show up in the printer, this way i can track where, why and when :)

Yeah, that can get "fun" at times. The GUI say the job is gone/there, but the wire activity doesn't quite actually agree, and the printer isn't responding at all. I hate when that happens.

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.

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.

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.

DoXiD

  • Participant
  • Joined in 2011
  • *
  • Posts: 5
    • View Profile
    • Donate to Member
Re: [Python][Windows] Debug/Gather printer information
« Reply #4 on: April 26, 2011, 09:17 AM »
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.
http://www.youtube.com/watch?v=plLrAZrvq3I
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 :)

Stoic Joker

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 6,517
    • View Profile
    • Donate to Member
Re: [Python][Windows] Debug/Gather printer information
« Reply #5 on: April 26, 2011, 03:03 PM »
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.

For the most part, the printer errors aren't worth the trouble. There is no consistent (RFC/Industry Standard) location for the error data, and if the printer actually does throw a truly Critical Error ... It'll be lucky if it can record it in its own logs before locking up. Anything else can be pulled out of (an SNMP query for) the Display text in real time (supplies out/paper jam - [User stuff]) which is in a standard location.

Now if you can track which ring of hell the print job just fell through on the communication side... That would be Uber Handy.


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 believe that there's no problem that can't be solved, the only question is who will come up with the answer :)

Agreed. But I have seen features turn into administrative nightmares because of differences between where a given piece of information is stored between different makes and models. Interrogating the driver/spool probably is the safest bet, but permissions issues come into play then also.


I'm looking in to the direct IP (TCP) printing as we speak, 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 :)

I may be missing what you're after here. but to me Direct IP is way simpler to deal with. The spooler client side is just a cache that frees up the application quicker so the print job can crawl up the wire. Print servers really just allow for another place for the job to get stuck ... Especially when the spooler becomes badly fragmented because it was left in the default location on a high traffic print server.

I just love it when a client's IT department swears everything is clear...Only to watch the printer vomit paper for a half an hour just seconds after coming back on-line.


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.
http://www.youtube.c.../watch?v=plLrAZrvq3I
1min 41sec into the video:
"i did wanna show you one thing tho that surprised 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?).

Ah! lol Yes, that was mouser in the video ... I do 99% of the printer configuration through the Embedded Web Server, and only physically touch the printer if forced to.

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, haven't been here long enough perhaps but i haven'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 :)

Thank you. Most of the simple stuff are just by request programs done by members to help people with simple requests. But there are many extremely talented programmers here, most of which are far better at it than I. My nitch is Network Deployment & Server Administration, programming for me is a hobby. Or rather it was supposed to be a hobby, until the boss found out what I could do. I designed and scratch wrote many of our company's internal database systems. Page Countster was/is also a company project.