Description of problem: I have an Officejet 6110 with the duplexer attachment. The way it's supposed to work to print a multipage document using that duplexer, the first page prints, the printer pauses to let the ink dry, and then draws the paper back into the duplexer where it is "flipped" over so the other side is presented to the print head for the second page. At the end of the second page the paper is put into the "out" tray. If I'm printing a job with an even number of pages, all works fine. But, if the job has an odd number of pages, that last odd page will be drawn back into the duplexer - and it stays there. Every time. Mageia says the job is done, but the printer says it isn't. Using the cancel button on the printer does nothing. To get the paper to eject, I have to cycle the power button on the printer. Documents that are printed single-sided print normally. Version-Release number of selected component (if applicable): Having little knowledge of the guts of this stuff, I have no idea if this is a HPLIP issue, a CUPS issue, or something else altogether. I see that Mageia uses hplip 3.11.3a. I had the same problem with Mandriva 2010.1/2, using hplip 3.10.2. I did not have it with earlier Mandrivas. How reproducible: Always Steps to Reproduce: 1. Print a document with an odd number of pages double-sided with the duplexer. 2. 3.
CC: (none) => cjw
Mandriva 2010.2 has updated hplip to version 3.11.5. This problem is still there.
Have you reported this problem directly to hplip developers? http://hplipopensource.com/hplip-web/support.html Please read the instructions below the "Report a bug" button.
CC: (none) => doktor5000
I've only reported it here. While I strongly suspect hplip is at fault, I don't have the knowledge to be certain it isn't something else. I had hoped that someone with that knowledge would take a look, and pass it along to the correct organization if appropriate.
Somebody with the knowledge might not have the duplex unit, or your exact printer model and installation, and maybe can't even reproduce the bug. If you want it fixed, you should open up a bugreport with hplip developers, and at least give them the output of hp-check -t and hp-info -i.
Bug has been reported since March 2009. https://answers.launchpad.net/hplip/+question/64229 Apparently it exists for several printers and duplexers, in several distros.
I don't know what's going on now. Somebody connected with hplip installed hplip 3.11.7 manually into Mandriva 2010.2, tried his duplexer with a LibreOffice document, and it worked as expected. I tried the same thing, and mine failed yet again. I'm beginning to wonder about the printer itself, but it's mystifying. There's another Mandriva problem, where the test page printed from the hp manager prints itself across three pages. It prints about a third of the page, then ejects it and prints about a third on another page, then ejects that one and prints the rest on a third page. That problem persisted after the Mandriva update to hplip 3.11.5, and after my manual install of hplip 3.11.7. However, it doesn't exist in Mageia 1 with hplip 3.11.3a. It appears that something other than hplip must be affecting things, but I just don't know what it might be. I think the best thing to do now is just to wait for the upcoming Mageia hplip update, and see what happens then.
Keywords: (none) => UPSTREAMCC: (none) => stormiAssignee: bugsquad => suppSource RPM: (none) => hplip
Status: NEW => ASSIGNED
The hplip update didn't help. The printer itself has been cleared, as has the duplexer. I moved the duplexer attachment to a Deskjet 5650 printer, and it did the same thing. Printing from a VirtualBox 4.1.2 Windows XP guest (Mageia host) worked as it should, thus clearing the possibility of a hardware problem. At one time I suspected that perhaps something else I installed was causing the problem, but a new Mageia install with no "extras" still does the same thing. I am using a Sempron 3100+ processor on an Asus KV8-MX/S motherboard with 2GB DDR RAM and a Geforce 6200 AGP video card.
There were no changes in the recent hplip updates regarding duplex printing so far. Could you please try to print an odd-numbered printjob via the duplexer and then add your /var/log/cups/error.log as an attachment here?
Created attachment 881 [details] cups error log
No error log was created when I attempted to print three pages in duplex. The attachment was generated when I attempted to print a single page with the final page of the previous three-page job still "stuck" in the printer.
Would you also please attach your /etc/cups/printers.conf
Created attachment 883 [details] printers.conf file
In the for-what-it's-worth department, when I print one of these documents a notification that the print job was successfully completed pops up while the last printed page is drying, before it is taken back into the duplexer to be turned over - and gets "stuck." So I'm not surprised that it doesn't generate an error report. It's probably an inaccurate description, but from my chair it looks as if there should be one final "page eject" command given to the printer at the end of the job when the duplexer is used. The problem is, though, that I don't know what such a command would do when there is an even number of pages, so no doubt that "solution" is too simplistic. It also doesn't explain why the HPLIP guys couldn't duplicate the problem with Mandriva 2010.2, when I had it with Mandriva 2010.1 and still had it when MDV morphed into 2010.2. The last time the duplexer worked properly was with Mandriva 2010.0.
Sorry - in all these descriptions I failed to mention that I'm using the 32-bit Mageia, and the installer installed the server kernel. When I was using Mandriva 2010.1 I switched to the desktop kernel because my motherboard has a maximum of 2GB of RAM, but with Mageia I continued to use the server kernel, and when I switched to Mageia and installed a backup Mandriva 2010.1/2 in case Mageia didn't work for me, I retained the server kernel. Both kernels showed the problem.
The hplip guys can't reproduce exactly as they don't use either Mandriva or packaged version of hplip, they directly use the hplip installer, that would be your last resort to try out. From your printers.conf, i see the following device URI: DeviceURI hpfax:/usb/OfficeJet_6100_Series?serial=MY31FC24G82R Should rather be hp:/usb/... Can you try changing the connection of the printer, and post here what connection methods (device URI's) it offers to you? Proceed as described in this post: https://forums.mageia.org/en/viewtopic.php?p=6045#p6045 Only disregard the last paragraph about the usblp module.
Are you sure about that? The Officejet has printer, scanner, copier, and fax functions. The fax part has always installed as a separate device, identified as a fax device. But anyway, here are the choices offered when I attempt to "modify" the HP-FAX device: SCSI Printer HP OfficeJet 6100 Series (HP OfficeJet 6100 Series) hp deskjet 5600 (hp deskjet 5600) HP OfficeJet 6100 Series USB MY31FC24G82R HPLIP (HP OfficeJet 6100 Series) HP deskjet 5600 USB MY43N4N20679 HPLIP (HP deskjet 5600) OfficeJet 6100 Series USB MY31FC24G82R HP Fax HPLIP (HP Fax) BTW, I switched the duplexer attachment to the Deskjet 5650 at the request of one of the HPLIP guys, to see if the problem was unique to the Officejet. (The same duplexer fits both printers) It wasn't. The problem switched with it. The duplexer is still on the Deskjet. If you want me to put it back on the Officejet, let me know.
Ah sorry, didn't see that your printer is listed seperately at the top of the file, no, that should not be a problem. When you try to modify the printer, does it offer you two different device URIs for one of these models? Like one hpfax:/usb/... and one hp:/usb/... or something similar? Now normally you would also need to check every combination of printer, duplexer and printer-driver.
The offers are shown as above, with check boxes next to them. Note that each of the printers shows one with "USB" and "HPLIP" included, but the other does not. Fax offers but one. So far, I have not gone so far as to actually try the other option for one of the printers. I will try one of them tonight, after my workday is done. An additional piece of information: The Deskjet 5650 can connect via either usb or parallel ports. I use usb. The Officejet is usb-only.
I modified the Deskjet twice tonight, using each of the above 5650 selections. According to what I was seeing, each of the printers was still using the 3.11.3a driver. Modifying it changed that to the 3.11.7 driver. However, it still does the same thing in each trial.
Oops. By "the same thing" I meant that the duplexer problem still exists.
When checking all the combinations, i've at least three other options. You could try rasterview http://www.easysw.com/~mike/rasterview/index.html to directly check the data which is sent to the printer and see if there is any odd stuff going on there at the end which could confuse the duplexer. Another would be checking if hplip 3.11.10 clears the problem, which was released just recently and the other would be to completely remove the hplip packages and install hplip directly via the hplip installer.
For various reasons that are unimportant here, I wasn't able to continue checking on this problem until now. Still using hplip 3.11.7 as updated from the Mageia repositories, on a fully-updated 32-bit Mageia 1 install. Earlier this evening I printed two two-page pdfs with Adobe Reader 9.4.2 using my HP Deskjet 5650 and the same duplexer mentioned earlier. Before, neither would have worked properly. But this time, both printed just as they were supposed to, with the final page ejected when finished. I have no idea why the problem has disappeared, but it has. There's been a kernel update or two since my last trial, and if I recall correctly CUPS was updated at least once. Maybe it was one of them. But for now, unless somebody else has the problem, I'd say you can mark this "bug" solved. A big "thank you" to all who worked on the problem, and an even bigger one to whomever made it go away.
OK, feel free to reopen if it happens again :)
Status: ASSIGNED => RESOLVEDResolution: (none) => WORKSFORME