Luminous Landscape Forum
Raw & Post Processing, Printing => Printing: Printers, Papers and Inks => Topic started by: fred.carter on April 18, 2019, 06:53:05 pm
-
I know that Mojave is not kind to printing. And Epson is not quite up on things all the time. That all said, this one was strange.
Versions, etc.: Mojave (10.14.4), Epson P800 (10.16) connected over wireless.
Task Details: Printing 25 "contact prints" (3x2 -- 5 rows of 5 images, landscape) to (one page) A3+ (13x19) paper (HahneMuhle, glossy, if it matters) from Adobe Lightroom (most recent CC Classic version). Printing B&W prints, so Lightroom told to let printer manage color, and printer set for Advanced Black & White mode. 16-bit on.
Situation:
- Last week -- worked fine, as expected.
- Last night (with no software change): Lightroom churns for a while building print job. While this is going on, print queue shows job as "incoming" (normal). When Lightroom is nearing the end of its work (but not yet done), the print queue window appears to think it should start printing (shows job as printing 1 of 1 or whatever). When Lr finishes, job is instantly converted to "Aborted". Looking at error log & console log, it has a "client error" indicating that no files were available.
Resolution?
- Rebooted to no avail
- Reset printing system to no avail (but high annoyance >:( ).
- On the
theory guess that it was dropping out early for some reason, I tried cutting down the number of "contacts" (still just 1 A3+ page). 24 contacts -- same, 23 -- same, 20 -- it works fine.
Question: Is there some inherent limit that anyone knows about on the sizes of the print jobs? The difference between last week & this week was that the images were all edited to have deeper blacks & more dimension/separation -- that is, print image quality improved.
Thanks in advance...
/fred
-
Hard to say, but looking at the most obvious thing first - previews of files can show without the files themselves being recognized by Lightroom if their location on your hard drive by any chance now differs from where your Lightroom catalog thinks they are. This can happen is you changed file locations "behind Lightroom's back" rather than from within the Library Module of Lightroom. Did you do anything like that? If so, could be that the Print module couldn't access the data, triggering that error. Not saying this is necessarily what happened, but guessing from afar - a possibility.
-
Thanks, but the underlying raw files are all there. Lightroom is quite happy with the print job. It finishes without error.
The issue is that the print queue appears to start sending things to the printer before Lightroom has finished producing the print job. Then, when Lr finally finishes, the job's aborted.
Making the job "smaller" appears to avoid the issue (and I could then have a second job that prints more "contacts" separately successfully). I don't know if it's really a print job sizerelated issue or not. That was just the workaround.
-
Fred,
I'm working with the same OS and same Epson drivers. Without any issues.
The only difference between our set ups is I'm using USB instead of WIFI.
-
I’ve found WiFi and the sc p800 unreliable and prone to incomplete print jobs. This, even with the printer only 6 ft from the router. USB, no problems.
-
WiFi issues possible, but worked fine with smaller job. And timing was very consistent. WiFi issues would tend to vary. But will be worth trying a USB or wired connection. Thanks!
That said, the error log content...
E [17/Apr/2019:21:50:17 -0700] [Job 3] Aborting job because it has no files.
E [17/Apr/2019:21:50:40 -0700] [Client 44] Returning IPP client-error-not-possible for Set-Job-Attributes (ipp://localhost/jobs/3) from localhost.
E [17/Apr/2019:21:57:10 -0700] [Job 4] Aborting job because it has no files.
E [17/Apr/2019:21:57:41 -0700] [Client 59] Returning IPP client-error-not-possible for Set-Job-Attributes (ipp://localhost/jobs/4) from localhost.
-
Since WiFi performance often is a mystery unless you have some tools I wouldn't discount WiFi as the source of your issues. Bandwidth and buffering of data in your computer or P800 may be worth considering.
You might consider getting "WiFi Scanner" from the Mac App Store to see what is really going on at a somewhat high level or some other tool.
The app will detail all the WiFi signals it can detect along with Signal strength, Noise, Channel, Band, Mode, Security and Max Rate. If you're a network engineer you might consider this pretty rudimentary but it may also be what you need for determining if your WiFi is sufficient.
-
I've been experiencing "filter failure" errors when printing to my Epson P800 hardwired to my LAN using Capture One Pro 12. The error occurs only when printing sizes greater than 8x10. I've tried the usual things, uninstalling and reinstalling drivers, etc, to no avail. My workstation is a first generation iMac Pro running Mojave. The problem started with Mojave.
Neither Capture One, Epson or Apple tech support have been able to help on this.
My workaround is to create a TIFF of my final image and then print using On1 Photo RAW 2019. I can also print from Apple Preview without any issues.
I just installed the Epson Print Layout to use as a plug in for Capture One Pro. I have not tried this yet, so we shall see if it solves the problem.
Regards,
Bud James
Please check out my fine art and travel photography at www.budjames.photography or on Instagram at www.instagram.com/budjamesphoto.
-
I just installed the latest version of Capture One Pro 12, version 12.0.3, and made a few prints from within the app. To my pleasant surprise, I printed a few 11x14 prints on 13x19 paper without any "filter fail" errors. Perhaps the latest update addressed the problem that I was having printing to my Epson P800 printer.
Keeping my fingers crossed for now.
Regards,
Bud James
Please check out my fine art and travel photography at www.budjames.photography or on Instagram at www.instagram.com/budjamesphoto.
-
A potential answer. There was a thread/topic 7 years or so ago about maximum CUPS size. It didn't appear that there was ever a true resolution. That topic can be found at Maximum spool file size when using Mac/CUPS? (https://forum.luminous-landscape.com/index.php?topic=70134.0).
(CUPS is the underlying print system in MacOS. Formerly, Common Unix Printing System, now just CUPS.)
I looked at the various CUPS docs & configurations to see if there were any limits engaged by default -- there do not appear to be. The default value is zero (0), meaning unlimited. (Well, sort of unlimited, I think.)
So I downloaded the source code for CUPS. Therein, I found that the limit on file size within CUPS is stored in a C-language integer. Generally, these are 4 bytes long, with a maximum value of 2 Gig. So, my educated guess is that the spool file was larger than was trackable, and that caused the print job first to begin attempting to run, then to abort, probably due to arithmetic overflow or inability to compare to actual size.
More research required (specifically what the spool file size actually is). But this line of inquiry looks promising.
-
I print infrequently so every job is a 'fingers crossed' business. But I've found that even printing through USB there is at least one 'choke point' between LR/Mac (MBP with a lot of RAM) possibly due to CUPS (see above). But I don't know for sure. The problem is that Mac OS offers NO help in diagnosing printing problems. Zip! So I have no information on where the critical point of failure may be.
But I have found by experiment that printing to A2 sized prints on my SC-P800 is reliable ONLY when I limit the LR DPI of the print to at most 480 dpi (printing in 16-bit color). I set the printer dialog to print at "Superfine 1440 dpi" however, which is exactly 3x the LR DPI. This appears to give me very fine resolution on the paper and (most importantly) no aborts.
i suspect the problem is not hardware related on either side of the print pipe-line. I think it's a software issue. I'd love to find a specialised piece of Mac OS software that would examine/reveal/correct the problems. If you know of such an utility, please let everyone know.
Best, P
-
Problem solved.
As it turns out, the actual problem had nothing to do with the job size, per se. Instead, it had to do with the time it took to produce the job.
From the looks of things, Lr makes the connection to the printer at the time it starts to build the print job. On my MacBook Air, producing that print job took over 5 minutes. As it happens, 5 minutes (300 seconds) is the default timeout period. So, most of the way through the job, it timed the job out, cancelled it, and marked it aborted.
Solution: Increase the timeout period to some number sufficiently large. Specifically, in the terminal, run
sudo cupsctl Timeout=5400
(sudo -- as the admin) (cupsctl -- program controlling the printing system) (Timeout -- the timeout parameter) (=5400 -- 90 minutes in seconds)
Diagnosis mechanism: (I'm a software developer of nearly 40 years, so that helps here.)
- Open the print queue -- from the Printer menu, bring up the error log -- see nothing of value
- Turn on debug logging -- sudo cupsctl Loglevel=debug
- Attempt to print. Watch for errors...
- Eventually, find message of the form Timeout after 300 seconds
- Search web for that message. Find similar hints, find someone who looks at Timeout CUPS config
- sudo cupsctl Timeout=5400
- ;) 90 minutes should be long enough.
- Retry print job. Success! 8)
Admittedly, a bit involved. Having low-level system server development experience helps.
-
Well done! Have to remember that one: cupsctrl.
What would it have taken for the developers (of the printer driver?) to give you (us) a meaningful error message such as "Sorry, you ran out of time (300s) in the print job preparation" instead of "job aborted!"?
Lazy! Instead you had to dig through Log files!
Since you are a developer of longstanding you may remember Don Knuth's wonderful essay "The Errors of TeX" (ungated version here::https://yurichev.com/mirrors/knuth1989.pdf) in which he shows how to write a REAL error message, among many other useful ideas. If only modern developers had the same humility and cared so much about their craft. (I'm prepared to believe they do but suffer disincentives).
P
-
Excellent detective work, and makes me wonder why such detective work should be necessary in the first place. I think it worthwhile bringing this matter to Epson's attention. While it seems to be an unusual problem, perhaps they could design something into the next version of the firmware or driver to make it easy for users to determine whether they have this issue and provide an accessible control for augmenting the timing.
-
Excellent detective work, and makes me wonder why such detective work should be necessary in the first place. I think it worthwhile bringing this matter to Epson's attention. While it seems to be an unusual problem, perhaps they could design something into the next version of the firmware or driver to make it easy for users to determine whether they have this issue and provide an accessible control for augmenting the timing.
Second the motion!
-
W THE ACTUAL F.... Good job Fred, I'm not sure how more than 5 people in the userbase were supposed to figure this one out. Poor little MBAir - the little laptop that could, if only given enough time.
-
Quote from: Mark D Segal on Today at 08:48:26 am
Excellent detective work, and makes me wonder why such detective work should be necessary in the first place. I think it worthwhile bringing this matter to Epson's attention. While it seems to be an unusual problem, perhaps they could design something into the next version of the firmware or driver to make it easy for users to determine whether they have this issue and provide an accessible control for augmenting the timing.
I don't disagree, though (unfortunately, putting on my software dev's hat again), the trouble in tracking this down is actually with CUPS. Lr took a long time (yeah, I should probably upgrade my machine) and then CUPS dropped the ball. To a large extent, it never even got to Epson.
CUPS is open source -- which means its available, I can look at the source, but there's no there there (i.e. no one to blame). Which means the responsibility to fix lies with Apple (as the consumer of CUPS here).
I have a ToDo to go find out how to file a bug... Maybe I can file a CUPS issue.
Thanks all -- hopefully this is of help to someone else. I'll add it to my Lightroom Special Needs class...
/fred
-
Thanks for the clarification.
-
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. ::)
-
I'm confused. Is the timeout period in Lightroom? Apple MacOS? Epson? Where is the fix needed?
Also... much RAM and disk space do you have in your MBP?
-
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. :)
-
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.
-
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.
-
That's a good thought, Mark. The only other possibility is that the 256 GB Mac drive has very little free space on it.
-
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.
-
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
-
Thanks, Fred. This thread has been enlightening.
-
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 :-;
-
Minor update on the state of things.
FYI:
- Apple bug: https://bugreport.apple.com/web/?problemID=50218003 (https://bugreport.apple.com/web/?problemID=50218003)
- CUPS bug: https://github.com/apple/cups/issues/5570 (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