Mojave/Lightroom/Epson P800 issue: print job "aborted"

[fred.carter]

It's a MacBook Air, early 2015, with 8 Gig of memory & 256 gig disk.  I use an external drive for the Lr catalog and images.

That all said, the Timeout parameter is a CUPS parameter.  What's happening is that Lr is producing the page to print & taking over 5 minutes to do so.  It tries to hold the connection open during that time, but CUPS (the printing system) times the connection out & closes it before Lr's finished producing the print.  Lr doesn't notice & generates no error.  And the print job just "goes away."

Note: What follows is some low level changes to the MacOS infrastructure.  If you are not comfortable with this, don't.  The changes being made will affect all printing within the system, so if you "do it wrong," things could be negatively affected.  This is a pretty harmless parameter, but you do need to be aware that you are changing things that Apple doesn't generally provide it's usual controlled access to (i.e. there's nothing in System Preferences that provides this capability.

So you are on your own.  Be careful. You are taking this risk on yourself.

To change the CUPS parameter, open the terminal (in the Utility directory within the Applications directory and/or Dock item), and type

    sudo cupsctl Timeout=5400

Which translates to...

• sudo asks the system to do this as the system admin (and it will ask for your login password),
• cupsctl is the CUPS control program,
• Timeout (capital T) is the configuration setting to change, and
• 5400 is the new setting to give it (the number of seconds before closing the connection/timing out)

Unless it's been changed, it's default setting is 300 -- or 5 minutes in seconds.

The Timeout is the length of time in seconds to wait before timing out connections.  On my machine for what I was doing, 300 seconds/5 minutes was not long enough (your system & print will vary).  I set it to 90 minutes (5400 seconds) because that was long enough for anything. You could certainly figure out the longest you'd ever wait for Lr to print something and set it to that.

[rdonson]

Thanks for the response, Fred.

I print from my 27" 5K iMac with 40GB RAM, quad core i7, 500GB SSD  and I've never had a timeout on printing anything.  Perhaps the difference is in the compute power between our machines. 

[Mark D Segal]

Regardless of the computer (provided it's contemporary) it's rather extraordinary that Lr would need more than five minutes to compute and spool a file to a printer.

[rdonson]

That's a good thought, Mark.  The only other possibility is that the 256 GB Mac drive has very little free space on it. 

[Wayne Fox]

I know that Mojave is not kind to printing.

I realize you stumbled across an interesting problem, but Mojave and printing works just fine, not really any different than any other OS out there.

Regardless of the computer (provided it's contemporary) it's rather extraordinary that Lr would need more than five minutes to compute and spool a file to a printer.

agreed, especially something going to a p800 which is only a 17” wide printer, even if it was a long pano on roll paper.  maybe the startup drive is too full which really slows macOS down, or maybe some other problems with the computer.

 But kudo’s to the OP for the time tracking this down and the solution, and I’ll probably use the terminal command “just in case”, as  I have seen filter fail error once when trying to print a 40” x 120" pano in 16bit, and never could figure out the error. The 16bit was a mistake (disabled it in LR, but it was still enabled in the driver), and switching to 8 bit solved it.

[fred.carter]

Re: Mojave not being kind to printing

My experience here is during the upgrade, at least.  Myself & many I know ended up having to restart/reset/reload the printing system numerous times to get things to settle down.  Once it's set, it's OK.  But there were issues in setup, with the driver, etc.

Re: Lr needing more than 5 minutes...

Machine is from 2015, so sort of contemporary, but not really.  Drive is about 1/2 full.  What, I suspect, makes the difference is printing 25 3x2 images on a single A3+, each of which having many edits to them.  It worked the week before -- to improve (primarily) the dimension & depth in the B&W prints, more was done -- at which point it failed.  Printing one large print is much easier than 25 separate ones.

If you search Adobe or things in general, you'll find folks speaking of the slowness of printing contact sheets. Due to the fact that there are 25 renderings going on.

Nonetheless, that was the issue.  And the fix worked.  Bugs filed all around...

Thanks for the help

/fred

[rdonson]

Thanks, Fred.  This thread has been enlightening.

[Daneman]

First post ever!

Reading this with interest, and as a former OS developer, that was good sleuthing - however, I'd lay the total "blame" on Adobe for (as Fred said) (1) opening the connection and holding it, and (2) not bothering to check if it was still open when it was finally ready to print.

No matter the timeout, one can always have a longer lasting processing job - the burden lies squarely on the OS client (Lightroom) to ensure the connection is available and to correct for errors.

My initial 0.02 :-;

[fred.carter]

Minor update on the state of things.

FYI:

• Apple bug: https://bugreport.apple.com/web/?problemID=50218003
• CUPS bug: https://github.com/apple/cups/issues/5570
• Added post to Adobe issues area: Lr shouldn't hold the printer connection while producing the file. Not a bug report per se, but as close as they appear to have.

Hopefully some good karma -- I have low expectations of any of these being addressed any time soon. 

Re: Apple bug:  I got a message that this was addressed in 10.15.

As a result of your feedback, there are software changes in build macOS 10.15 beta 1 (19A471t) that have resolved this issue.
Feedback ID 6078410, CUPS timeouts are not reported 50218003

(And I had had some interactions with the CUPS folks about this, so I'm not completely surprised. But to give Apple deserved credit,
at least this part of the overall issue has, in theory, been addressed in 10.15.  Based on the PR in Github, some message will appear AND
the default timeout has been increased.)


/fred