We have seen this error in the past. Sense the restarting of the Pharos services does not help I suspect that there are jobs hung in the MobilePrint Renderer queue on this server. Restarting the server is likely clearing the failed jobs and allowing the rendering of MobilePrint jobs to resume. You can tell if there is a problem related to renderer queue by opening the queue to see what is printing or you can use Print Management to see the jobs that are trying to print. There should not be any jobs that linger for more than a few seconds in the renderer queues. Once there is 10 jobs hanging up the 10 available MPPorts no more MobilePrint jobs will be able to render.
In my experiences with this issue it can be related to a particular job or there could be an issue with a print driver on the server. I recommend removing all the printer drivers from the server and reinstalling them. That should eliminate the possibility of a corrupt driver. If the problem persists then I would recommend starting a support incident with us to capture and review logging.
Barry, I have been seeing this same issue since applying the SP4 update and upgrading to Mobile Print 2.2. Whether it is germane or not, I see that my lab printers, which are served by my Uniprint server and are direct release, do not get these errors. But my Mobile Print printers, which are the exact same model printers, do get these error messages. One significant difference between the two setups is that my lab printers use a PS driver and the Mobile Print printers use a PCL6 driver. Can we use a PS driver for a Mobile Print printers? All documentation I have read on MP mentions only PCL drivers.
Mobile Print can use any driver you like on the "Rendering Queue" (merely a Windows Printer Object). We started shipping a Very generic version of a PCL Driver in the initial days of MP and it just stayed that way. Trying different drivers is always the "fun" part of printing so that the output is what is expected.
If that is somewhat PCL or PS related, I have a 'personal' beef with Postscript... The tendency of print jobs coming through in color despite having been set to b/w. Quite frustrating when you setup a printer with a postscript driver, then prepare a b/w white job (and set the printer to be b/w) ... and the job comes out in glorious color anyway because (as I understand it) the document still contains color codes despite the print settings.
Just my "beef" with Postscript.
- Paul L.
I know that my response here is incredibly OT to the OP, but I'm going to handle here. Rest assured, "surprise color output" is not actually a PostScript defect, but a Windows GDI one. And I wouldn't even call it a defect.
The Windows GDI (Graphic Device Interface) is the activity hub for many bits of the OS, but for our purposes we're just going to focus on Displaying and Printing. The entirety of the GDI utilizes the RGB (Red, Green, Blue), or Additive, color model when dealing with data. This is mostly because monitors, the predominant output device type for Windows, use Red, Green, and Blue picture elements (thus, pixels) to create the image you see on-screen. Because GDI feeds Spooler, the RGB model persists (which is programmatically efficient; you just pass the same values from one driver to another and let it manage the mess). So in the process of print, the EMF (Enhanced Meta File) created by the GDI and handed to the printer driver's print processor is also RGB.
Once the print processor receives the EMF, it uses the choices made by the user (or kept using the defaults) to further manipulate and create the spool file for the printer. But most drivers don't go through the hassle of converting colors. Instead, they plop in some key command:
- @PJL SET COLORMODE=GRAYSCALE <<PJL for a PCL file
- *SetRenderMode=Monochrome <<PostScript command
that is supposed to tell the printer (which is typically faster -- and better -- at this function) to convert the data to a different color mode.
And that's where the gloves come off. Some printer drivers, if you tell them the printer mode is Monochrome/Grayscale/Black & White, will actually not include any command to convert color because the black-toner-only printer on the other side has firmware that is smart enough to figure that out on its own, and the "convert the color bits to mono bits based on neutral density" event happens automagically. In other words, if I submit a job using a driver configured for a monochrome printer type to a color printer...I will get color output because the printer is only doing what it was told (and part of that was not converting to monochrome).
There are two ways to make the printer atone for this imbalance in The Force. The first, and most obvious way, is to configure the print device (via its Printer Setup screen or similar function) to default to monochrome output. Many do allow this. The only drawback with this arrangement is that the users must be able to access a printer driver/queue that allows them, if needed, to change the output type to Color, or you will never have to spend money on Cyan, Yellow, or Magenta toner again.
The second way is to define your print queues as if they were always attaching to Color printers, and then change the Printing Defaults within the driver to output Monochrome. I prefer this method, because within a manufacturer (mostly), you get consistent results regardless of the actual color support of the printer. A drawback (because everything has to have a Dark Side, it seems) is that a user -- since this option is a user-level control -- can override your sensibilities and default the user preference to Color. Which may require user education and some refunds until they all get the hang of it.
Have seen this issue several times here with SP3 and SP4 of Pharos 9.0 R2. I am currently on MobilePrint 2.1.
I fixed it by crashing the 4 rendering processes that between them will consume around 100% of the 4 CPU's on server. That make the system response to users again.
As to why, I have turned up my logging, but have not had issue appear again since logged is on.
I suspect its a driver issue,but lot of variables here. Make sure you have the two hot fixes for MP 2.1 from Aug 2015 as that might be part of the issue.
I just had this issue for the first time today. We upgraded Mobile Print from 2.1 to 2.2 over the weekend and updated to Pharos Uniprint R2 SP4 two weeks ago. I rebooted the Print server and everything was working again. If this happens again I will take Barry's advise and check the queues for any jobs hung up. I am a little worried since this is the first time we have seen this and I just update to Mobile Print 2.2 this past weekend.
I can't say whether my solution will work for everyone or not, but I have gotten this problem to go away, at least for now. It seems that it may have been related to the antivirus software we use, Symantec Endpoint. Once I set up an exception for the Pharos directories and the spool directory in Symantec, the timeout error went away and printing via MobilePrint is working as expected again. Worth a shot! One other thing, I also changed the print driver used from a PCL to a PS driver. Not sure if that had any effect on the problem but it is one other thing to look at.