Large spool files and PaperCut MF

13 August 2018

We can’t promise this blog post will be a riveting read, the glimpse behind the PaperCut curtain can be a bit geeky but bear with us, it might come in useful on your next install.

We recently had a valued partner install PaperCut at a large corporate customer for whom they implemented a filter within PaperCut to automatically delete print jobs that have a large spool file size.
For full disclosure we never found out why the customer wanted this and nor do we have a clue how spool files can end up so large sometimes, we like an air of mystery when it comes to print.

The customer had a healthy mix of Windows and Mac clients, the Mac’s were used for high-quality image file manipulation and the files would be sent to a very expensive printer living in the print room. The customers print server was Windows based and the Mac’s are printing via a printer shared on the Windows server.

In this particular setup/network, printing from Windows would cause the jobs to exceed a spool size of 2GB in around five minutes (pretty reasonable) and if that happened the job would be cancelled as per policy put in place.

spool size

Now, the same image files sent from a Mac often took a little longer than 10 minutes to spool. PaperCut queues the job for release at the 10-minute mark but at that point, the job is still spooling and may not have gone over the 2Gb limit yet. In this scenario, PaperCut’s filter does not trigger (as the spool file size is below the threshold) and the job sneaks through the restriction. So, we could blame the Mac’s but we really like them and we are not about blame here, we teach.

Get onboard our train of thought (choo-choo)

Default support reply of – update all the things! (PaperCut, drivers, OS).
Are they using Client Side Rendering? It could be moving the processing load of print-job rendering from the print server to the client computer would help speed it up.
Get some app and print logs from PaperCut, and as a bonus include event viewer logs from the print server to see what is happening.
Consider using Mobility Print for Mac printing, it can sometimes offer a better experience for the Mac users.

How we fixed it

During our morning triage we put our heads together and via a berry flavoured Huel moment of clarity, we remembered what to do!

As mentioned, PaperCut waits ten minutes for the print job to spool before performing any page analysis. If we had asked for and received logs, In the debug print provider logs, we would have seen something like this:

DEBUG: PrintMonitor.cpp:2468 - Timed out waiting for job 3 to spool (Timeout secs: 600). Try to process job.

Now, the timeout setting is actually double the ParseTimeout value found in the print-provider.conf file in [install directory]\PaperCut MF\providers\print\win.

If you open up the print-provider.conf file you will see this entry:

# The timeout in seconds associated with parsing printer spool files.
# Default: 5 minutes.
# Unit: seconds
# Examples: 600
#
#ParseTimeout=300

As you can see, the default is set to 300 seconds, multiply that by two and you have the 600 seconds (quick maths!) mentioned in the log file.

The next step is to work out how long the jobs take to spool, the customer already had a fairly good idea but if not, a bit of testing and trial and error will be needed. Let us assume that the jobs take 15 minutes to spool, that is 900 seconds, then you would need to set the value to 450. Whatever value you go for you will need to restart the PaperCut Print Provider service for the change to kick in, don’t worry any paused jobs will remain paused.

The print job will still be present on the server and will still occupy 2Gb of space on the machine until fully spooled. Oh and don’t worry, the setting will not impact smaller jobs, PaperCut does not currently wait 10 (or now 15) minutes for small jobs to spool.

As our man, KC famously said – here endeth the lesson.