Ubuntu

Brother HL-1430 USB printer will only print once

Reported by Peter Butler on 2006-08-21
32
This bug affects 3 people
Affects Status Importance Assigned to Milestone
cupsys (Ubuntu)
Low
Unassigned
Dapper
Undecided
Unassigned

Bug Description

Binary package hint: cupsys

I have a Brother HL-1430 printer connected via USB to a PC running Ubuntu 6.06 with all updates installed. The printer will print the first document I send to it perfectly, but any subsequent documents are held in the queue and not printed. The status in the printing applet is shown as "job-printing".

I set the log level in /etc/cups/cupsd.conf to debug, and /var/log/cups/error_log now shows the following (trimmed):

D [21/Aug/2006:17:11:32 +1200] [Job 113] End of page header
D [21/Aug/2006:17:11:32 +1200] [Job 113] Stopping search for page header options
D [21/Aug/2006:17:11:32 +1200] [Job 113] Found:
D [21/Aug/2006:17:11:32 +1200] [Job 113] ffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffff
D [21/Aug/2006:17:11:32 +1200] [Job 113] --> Output goes directly to the renderer now.
D [21/Aug/2006:17:11:32 +1200] [Job 113]
D [21/Aug/2006:17:11:35 +1200] cupsdReadClient: 6 POST / HTTP/1.1
D [21/Aug/2006:17:11:35 +1200] cupsdAuthorize: No authentication data provided.
D [21/Aug/2006:17:11:35 +1200] CUPS-Get-Printers
D [21/Aug/2006:17:11:35 +1200] cupsdProcessIPPRequest: 6 status_code=0 (successful-ok)

The last set of messages (about the authentication) are repeated every 10-30 seconds.

The output of lpstat gives:

# lpstat -a -p
HL-1430 accepting requests since Mon 21 Aug 2006 17:11:32 NZST
printer HL-1430 now printing HL-1430-113. enabled since Mon 21 Aug 2006 17:11:32 NZST
Printer not connected; will retry in 30 seconds...

This setup worked perfectly under Breezy (and other Linux distros such as Fedora Core 2), so I know there is no problem with the hardware.

I have also tried the following:
- Added cupsys to the "shadow" group
- Changed "Browsing" to "on" in /etc/cups/cups.d/browse.conf
- Changed all "deny, allow" lines in /etc/cups/cupsd.conf to "deny, allow"
- Changed permissions on /dev/lp0 to 777

I restarted cupsys (using /etc/init.d/cupsys restart) after each of these changes but the printer will still not print anything after the first job I send to it. I've also tried restarting via localhost:631 but no result.

I've also noticed that disconnecting the USB cable and reconnecting it causes all pending jobs to be printed. Does this point to a USB/udev problem rather than a CUPS problem?

Peter Butler (peter-butler) wrote :

Just tried installing and using the same printer via a parallel cable and it works fine. USB is still broken though.

AlterEgo (kipvogel) wrote :

Just a "me too". I hav exactly the same issue. Only on Dapper.
Switching the printer off and on again causes the next print job to start.

Xirtam (xirtam1985) wrote :

I can confirm the bug with the latest updates from main dapper repository.

Till Kamppeter (till-kamppeter) wrote :

Does the problem also occur on Edgy (try a live CD if you do not want to install Edgy)?

Till Kamppeter (till-kamppeter) wrote :

If you have an installed Edgy, try also to update cupsys to the newest version, as fixes on the USB backend were done.

Changed in cupsys:
status: Unconfirmed → Needs Info
Xirtam (xirtam1985) wrote :

I'll try this today. Now have to work :)

AlterEgo (kipvogel) wrote :

Tried Edgy (install from scratch) and found the problem gone ;-)

Till Kamppeter (till-kamppeter) wrote :

Seems to be fixed in Edgy, add a backport request if you need the fix for Dapper.

Changed in cupsys:
status: Needs Info → Fix Released
John Dong (jdong) wrote :

Is there any chance of getting this into dapper-updates instead of Backports? The nature of Backports in my opinion does not suit cupsys.

Peter Butler (peter-butler) wrote :

I agree. How do I submit a bug report to request that this goes into dapper-updates?

John Dong (jdong) wrote :

The Ubuntu Dapper side of this bug report is open. No further action necessary.

Lukasz Bruun (mail-lukasz) wrote :

I had this exact same problem with Edgy updated from Dapper and went through the whole process of reinstalling Edgy from scratch, because AlterEgo said this worked.

However this did not fix it for me. I still have either power off and then power on or pause/resume printer jobs to print all jobs after the first.

Bananabob (bananabob) wrote :

I just want to add a "me too"

I have HL-1430 and Edgy.

The printer will print once and then I have to unplug the USB cable and replug it to get the printer to print remaining jobs.

I note that some people report that this is fixed, but no one tells us how to fix it.

Bananabob (bananabob) wrote :

I am running Edgy and the problem still occurs

Changed in cupsys:
status: Fix Released → Needs Info
Peter Butler (peter-butler) wrote :

Did you install Edgy from scratch (rather than update from Dapper)? The message from AlterEgo above seems to suggest that installing from scratch will work. I have installed Edgy here but my printer is currently in transit, so I can't try it yet.

Bananabob (bananabob) wrote :

Installed from scratch onto a newly built PC.

AlterEgo (kipvogel) wrote :

Just to confirm my previous post: a fresh re-install of Edgy fixed my problem (half October 2006). However: the problem has returned for me too. I don't know when this happended or what caused it, but occasionally I have to power-cycle my HL-1430 in order to get the remaining prints.
I'm very sorry if I gave you guys false hope.

I am currently playing with Feisty, and I will report my findings.

Bananabob (bananabob) wrote :

I believe I may have found a solution to this problem.

I Tried to add Brothers own lpr and cups driver as per
http://solutions.brother.com/linux/sol/printer/linux/cups_drivers.html#de
Needed to issue "sudo mkdir /var/spool/lpd" as the first dpkg aborted with

mkdir: cannot create directory `/var/spool/lpd/HL1430': No such file or directory

I ran the install again and it was ok. I then installed the cupswrapper but got

lpadmin: Unable to copy PPD file!

Printer still worked after this but still has same printing only once problem. So I decided to ignore the PPD file error.

I then deleted the existing printer definition "System>Administration>Printers" right click on printer "remove". Created a new printer by clicking on "New Printer". Then for the driver part of the definition I set the Manufacture to Brother and selected "HL-1430 for Cups" in the Model section. The Driver was set to Standard - there were no others available.

Since then the printer appears to operate correctly, BUT, I have had to reset the printer by unplugging the USB cable at least one since doing the above.

I have a feeling that the problem may be linked to printing from different programs one after the other, but have been unable to recreate the problem.

Would all of you people suffering from the problem, like to give my solution a try and report back.

Lukasz Bruun (mail-lukasz) wrote :

I tried to install the install Brothers own driver as suggested by Bananabob and this didn't work.

I found some information at http://solutions.brother.com/linux/sol/printer/linux/linux_faq-2.html

What I did was, download the LPR and cups driver as suggested and then:

sudo ln -s /etc/init.d/cupsys /etc/init.d/lpd
sudo dpkg -i hl1430lpr-1.1.2-1.i386.deb
sudo dpkg -i cupswrapperHL1430-1.0.2-1.i386.deb
lpadmin -p HL-1430 -E -v usb://Brother/HL-1430%20series -P /usr/share/cups/model/brhl1430_cups.ppd

However, this didn't change anything, I still have to power off and on or pause and resume jobs to print pages after the first one.

I think the problem might be related to cups/usb, since after I print the first page and then remove the printer and try install it again in Gnome, it isn't autodetected, unless I power off and then power on.

I find it odd that I can pause the job in the print queue and then resume it and then it will start printing, as if pausing puts the printer in some state which makes it possible to print again. However this doesn't always work the first time, suggesting that it might be a timing issue?

Lukasz Bruun (mail-lukasz) wrote :

I came to realize that that my previous post did not install the "HL-1430 for CUPS" driver.

What needs to be done in order to install the correct driver is:

sudo ln -s /etc/init.d/cupsys /etc/init.d/lpd
sudo dpkg -i hl1430lpr-1.1.2-1.i386.deb
sudo cp /usr/share/cups/model/brhl1430_cups.ppd /usr/share/ppd/
sudo dpkg -i cupswrapperHL1430-1.0.2-1.i386.deb

This driver seems to work better, however I still had to power off / on the printer occasionally, like I had to in Breezy.

However I noticed a strange thing. In Gnome, when checking Properties -> Connection for printer, it is sometimes listed a detected local printer, then it's detected as a network printer with the URI "usb://Brother/HL-1430 series" and then it's detected as network printer the URI "ipp://usb://Brother/HL-1430 series"

So it seems that the USB connection is lost after printing the first job, since the printer is no longer detected as a local printer after printing the first job.

Lukasz Bruun (mail-lukasz) wrote :

Hopefully the last comment from me today :-)

I just want to point something out.

After turning on the printer and typing "lpinfo -v" in a console i get my usb printer listed as "direct usb://Brother/HL-1430%20series" , then I print a job and run "lpinfo -v" again and if the printer is still listed as "direct usb..." I am able to keep printing jobs, then after a number of jobs, the printer disappears from detected printers using "lpinfo -v" and a restart of the printer is necessary.

Peter Butler (peter-butler) wrote :

> after a number of jobs, the printer disappears from detected printers using "lpinfo -v" and a restart of the printer is necessary.

Can you check whether the printer device file still exists under /udev? I'm not sure what the device file will be called (I don't have my printer to hand at the moment). Does it still exist in lsusb?

Lukasz Bruun (mail-lukasz) wrote :

The printer udev file exists and the device is still listed using lsusb, after the printer no longer is listed with "lpinfo -v"

"crw-rw---- 1 root lp 180, 0 2007-02-15 13:53 /dev/usblp0"

And lsusb gives this

"Bus 002 Device 012: ID 04f9:001a Brother Industries, Ltd HL-1430 Laser Printer"

AlterEgo (kipvogel) wrote :

Tried the same printer on Feisty (14 Feb. 2007).
The printer still needs a powercycle to continue printing after the first document. Remarkably (?), printing also continues after I put the laptop in suspend: when it wakes up after suspending, printing automagically resumes. I believe the entire USB subsytem is restarted after suspending.

Lukasz Bruun' s comment shows that the CUPS "usb" backend (this one feeds "lpinfo -v" with information) looses track of the printer whereas the printer stays visible for the kernel and the rest of the USB subsystem.

So for me it looks like a bug in the "usb" backend. Will report it upstream ...

Reported problem upstream:

http://www.cups.org/str.php?L2243

Changed in cupsys:
importance: Undecided → Low

Mike Sweet has answered already to the report.

To make sure that the problem is really on the CUPS side, try the following:

Edit /etc/cups/cupsd.conf so that it has a line "FileDevice Yes", then restart CUPS with "sudo /etc/init.d/cupsys restart" and create a queue for your printer using the URI "file:/dev/usblp0" and the same PPD file as for your current print queue. This surrounds the USB backend. Tell whether you can print normally using this queue.

Bananabob (bananabob) wrote :

<quote>Edit /etc/cups/cupsd.conf so that it has a line "FileDevice Yes", then restart CUPS with "sudo /etc/init.d/cupsys restart" and create a queue for your printer using the URI "file:/dev/usblp0" and the same PPD file as for your current print queue. This surrounds the USB backend. Tell whether you can print normally using this queue.</quote>

The edit bit I understand, but as for <quote>create a queue for your printer using the URI "file:/dev/usblp0" and the same PPD file as for your current print queue.</quote> I am completely lost as to what you want us to try.

Bb

Do

lpadmin -p test -E -v file:/dev/usblp0 -m foomatic:Brother-HL-1430-hl1250.ppd

Then try to print to the new printer named "test". Can you print more than one job to it?

Bananabob (bananabob) wrote :

I have carried out the instructions you gave above, and I can report thjat everything now works using the "test" printer.

What is next?

Do I need to delete the changes made to cupsd.conf and delete the test printer?

To be able to print until the USB backend gets fixed modify your original print queue so that it uses the "file:/dev/usblp0" URI:

sudo lpadmin -p <name of your original print queue> -E -v file:/dev/usblp0

Delete the "test" printer:

sudo lpadmin -x test

but leave the "FileDevice Yes" in /etc/cups/cupsd.conf.

Now you will be able to print for the time being. As soon as we have a real fix we will post here.

Changed in cupsys:
status: Needs Info → Confirmed

Please move your /usr/lib/cups/backend/usb into your home directory and then download this file

http://www.linux-foundation.org/~till/tmp/usb

and put it into /usr/lib/cups backend. Make it executable with

sudo chmod +x /usr/lib/cups/backend/usb

Then set up a print queue as usual, using the auto-detected entry of your printer. Can you print normally now?

Note: My file is only for 32-bit architecture. If you are working with 64-bit or non-PC, do not install this file.

Changed in cupsys:
status: Confirmed → Needs Info
Bananabob (bananabob) wrote :

I made the changes and it does work.

Reported your results upstream. Thank you.

Changed in cupsys:
status: Needs Info → Confirmed
AlterEgo (kipvogel) wrote :

http://www.linux-foundation.org/~till/tmp/usb
Your file works as promised.
BUT: when I now switch on a printer, my USB storage disconnects.
Can someone please try and repeat this observation?
many thanks!

Lukasz Bruun (mail-lukasz) wrote :

I tried to used the 'usb' binary provided by Till Kamppeter and I no longer have any problems. Great job on fixing the issue!

As for AlterEgo's comment on his USB storage which disconnects. I tried to hook up my iPod Shuffle via USB and turn my printer off and on to see if the iPod got disconnected, it didn't.

I would like to mention that I have my printer connected directly to a USB port in my computer and not via any USB hub with other devices. I don't know if it would make any difference if the iPod and my printer were connected to the same USB hub, but I thought I'd mention it.

AlterEgo (kipvogel) wrote :

The disconnects last only a few seconds, then a re-connect automatically occurs. This happens on both an USB ext. harddisk and a flashdisk. I Noticed the disconnect because of error messages in an rsync-backup.

I repeated my findings from yesterday; see the log-file attached.

***** are my comments.

The problem of the Bother printers only printing one job is fixed upstream now. See

http://www.cups.org/str.php?L2243

Bananabob (bananabob) wrote :

Thank you for the quick fix.

There is another bug report at https://launchpad.net/ubuntu/+source/cupsys/+bug/69265
which describes the same fault.

Can I delete the usb file that I copied to my home directory, or shjould I hold onto it - just in case?

Changed in cupsys:
status: Confirmed → Fix Committed
Changed in cupsys:
status: Fix Committed → Fix Released
Gletscher (gletscherspalte) wrote :

i still have that issue in hardy, its totally not fixed for me

Martin (agima) wrote :

I can confirm that this issue still exists in intrepid, too.

Gletscher, Martin,
Please provide the information described here: https://wiki.ubuntu.com/DebuggingPrintingProblems, including your cups error_log and the output of the printingbug info script.

wwjd (wwjd) wrote :

I confirm this issue still existing in karmic. I used "ubuntu-bug cups" for reporting and had to open a new bug.
Please follow me to bug #466258. Thanks!

wwjd (wwjd) wrote :

This bug is still not fixed for me in Ubuntu 10.04 (Lucid Lynx).

Note: I'm using a 64-bit system.

Quote from Till Kamppeter
"Note: My file is only for 32-bit architecture. If you are working with 64-bit or non-PC, do not install this file."
Could it be that this bug is fixed only for 32-bit systems?

However, the proposed workaround does the job:

1. Edit /etc/cups/cupsd.conf so that it has a line "FileDevice Yes"

2. sudo lpadmin -p <name of your original print queue> -E -v file:/dev/usblp0

Please tell me, if I should provide more info.

wwjd

Thank you for posting this bug.

Is this an issue in Maverick?

Changed in cupsys (Ubuntu Dapper):
status: New → Incomplete
Andrew Clay (aclay-c) wrote :

This is still an issue in Maverick as well as Mint Julia

Further observations:-
If another job is sent very soon after the first job, it will print OK.
If the time between jobs is long, the next job prints OK.

I haven't determined the actual cutoff times for these conditions
The problem occurs between these two conditions.

Can you try with live CDs of Natty and Oneiric?

Closing Dapper task because Dapper is not supported any more. Please reopen if you still have the problem with up-to-date versions of Ubuntu.

Changed in cupsys (Ubuntu Dapper):
status: Incomplete → Invalid
Arie Maaskant (arimaask) wrote :

It looks like the bug returned in the beginning of August on Ubuntu 12.04 (64bit)
See the text in #1038695

"After an update of cups from 1.5.3-0ubuntu1 to 1.5.3-0ubuntu3 my
HL-1430 laserprinter is left in a wrong state. If I print a Libreoffice text
file containing two png images. It is impossible two print after this,
it takes very long to print afterwards and it is printing a blank page
at the most. After a powercycle of the printer, printing is possible again.
This only takes place on my 64-bits computer with Ubuntu12.04 64bits.
A simple Libre-office textfile with only text does not give any problem.

On the same computer there is a Ubuntu11.10 32bit system updated upto
cups 1.5.3-0ubuntu3 too. This doesn't give any problems at all, with the
same Libre-office file.

My (ugly) solution was to restore an old root-filesystem of 27 July 2012
and updating the system upto now *EXCEPT* cups.
I now have a completely updated the system with cups 1.5.3-0ubuntu1 (!) and
wait for updating cups until this bug has been fixed."

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments