Brother HL-1430 USB printer will only print once

Bug #57050 reported by Peter Butler
This bug report is a duplicate of:  Bug #1363670: 8480dn. Edit Remove
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
cupsys (Ubuntu)
Fix Released
Low
Unassigned
Dapper
Confirmed
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?

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Xirtam (xirtam1985) wrote :

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

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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

Revision history for this message
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
Revision history for this message
Xirtam (xirtam1985) wrote :

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

Revision history for this message
AlterEgo (kipvogel) wrote :

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

Revision history for this message
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
Revision history for this message
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.

Revision history for this message
Peter Butler (peter-butler) wrote :

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

Revision history for this message
John Dong (jdong) wrote :

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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Bananabob (bananabob) wrote :

I am running Edgy and the problem still occurs

Changed in cupsys:
status: Fix Released → Needs Info
Revision history for this message
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.

Revision history for this message
Bananabob (bananabob) wrote :

Installed from scratch onto a newly built PC.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
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"

Revision history for this message
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.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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 ...

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Reported problem upstream:

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

Changed in cupsys:
importance: Undecided → Low
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
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

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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?

Revision history for this message
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?

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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
Revision history for this message
Bananabob (bananabob) wrote :

I made the changes and it does work.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Reported your results upstream. Thank you.

Changed in cupsys:
status: Needs Info → Confirmed
Revision history for this message
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!

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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

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

Revision history for this message
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
Revision history for this message
Gletscher (gletscherspalte) wrote :

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

Revision history for this message
Martin (agima) wrote :

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

Revision history for this message
Pascal De Vuyst (pascal-devuyst) wrote :

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.

Revision history for this message
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!

Revision history for this message
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

Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

Thank you for posting this bug.

Is this an issue in Maverick?

Changed in cupsys (Ubuntu Dapper):
status: New → Incomplete
Revision history for this message
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.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Can you try with live CDs of Natty and Oneiric?

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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
Revision history for this message
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."

Revision history for this message
xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob) wrote :

This bug has regressed.

Changed in cupsys (Ubuntu Dapper):
status: Invalid → Confirmed
Revision history for this message
xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob) wrote :

this is very similar to bug 1363670

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

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.