Config details of networked printer aren't saved

[Peter Hinch]

Mint 17 64 bit. When I run the printer configuration application (system-config-printer) it detects my network printer. If I then access Priner properties I can set the manufacturer and model number in the usual way and the printer works. However the settings don't survive a reboot.

The workround is to make a change to the Description field: the Apply button is then enabled and I can save the changes. Evidently the application doesn't register the changes to the printer's properties as a change requiring saving, and so leaves the Apply button greyed out.

This behaviour is consistent and repeatable under Mate and Xfce.

While the workround is simple the behaviour is confusing particularly to a new user.

[Till Kamppeter (till-kamppeter)]

Are you really using system-config-printer or are you using the GNOME printer setup tool from the Control Center? Try starting system-config-printer from a terminal window via the command "system-config-printer". Do you get the same user interface?

Can you reproduce the bug? Please tell the exact steps to reproduce it, including creating the print queue and how you manipulated it. Start system-config-printer via the command

system-config-printer --debug 2>&1 | tee log.txt

then reproduce the bug and after that attach the log.txt file.

Tell us also which printer you have and attach the PPD file from /etc/cups/ppd/.

Do the attachments one-by-one, do not compress the files and do not package them together. Thanks.

See also https://wiki.ubuntu.com/DebuggingPrintingProblems

[Peter Hinch (peterg-1)]

On 28/06/14 12:04, Till Kamppeter wrote:
> Are you really using system-config-printer or are you using the GNOME
> printer setup tool from the Control Center? Try starting system-config-
> printer from a terminal window via the command "system-config-printer".
> Do you get the same user interface?
>
> Can you reproduce the bug? Please tell the exact steps to reproduce it,
> including creating the print queue and how you manipulated it. Start
> system-config-printer via the command
>
> system-config-printer --debug 2>&1 | tee log.txt
>
> then reproduce the bug and after that attach the log.txt file.
>
> Tell us also which printer you have and attach the PPD file from
> /etc/cups/ppd/.
>
> Do the attachments one-by-one, do not compress the files and do not
> package them together. Thanks.
>
> See also https://wiki.ubuntu.com/DebuggingPrintingProblems
>
>
>
> ** Changed in: system-config-printer (Ubuntu)
> Status: New => Incomplete
>
As stated in my original report I'm using Mint 17. The printer
configuration utility accessed from the Control Centre is
system-config-printer V1.4.3 as reported by its About dialog box.
Running system-config-printer from the terminal brings up the same
version and UI.

The printer is a Canon Pixma iP5000 run as a network printer via a Qnap
TS119 NAS box. There are no issues with my setup: I use the printer from
two Debian boxes and have set it up and accessed it from other distros
including Mint and OpenSuse. The problem I've identified seems new and
to be associated with the automatic population of fields in the printer
properties.

On the machine under test the direcory /etc/cups/ppd/ is empty.

The steps in reproducing the bug are as follows.
1. Invoke system-config-printer (via UI or CLI) (log1.txt)
The network printer is detected and appears as the only printer.

2. Right click on the printer icon and select Properties.
The fields in the dialog box (which shouldn't be changed) are populated
as follows
Description: QNAP2(Airprint)
Location: QNAP2
Device URI: ipp://QNAP2.local:631/printers/QNAP2PR2
Make and model: Remote Printer
Printer State: idle

3. Click Change to change the make and model
Select Canon, then Pixma iP5000, then click Forward

4. Select "Use the new PPD..." and click Apply
The Properties dialog box appears with the Make and Model reading
Canon PIXMA iP5000 - CUPS+Gutenprint v5.2.10-pre2
Note that the Apply button is greyed out

5. Press OK and close the Printers dialog with the X button at top right.

6. Close the terminal, shut down the computer and turn off the printer

7. Restart the computer and run system-config-printer: note that the
dialog box states that no printers are configured.

8. Shut down the computer. Restart the printer. Restart the computer.
Repeat steps 1 and 2
The dialog box shows "Remote Printer" in the Make and Model field. Its
configuration has been lost. (log3.txt)

As a general point, when the software is working correctly (either by my
workround or on my Debian boxes) the printer details are saved, even if
the computer is booted up with the printer powered down or otherwise
unavailable. On a laptop in particular this scenario is commonplace.

A...

[Till Kamppeter (till-kamppeter)]

What is happening is the following:

Your NAS is a machine running Linux (or some *BSD) and uses CUPS to implement the print server functionality. As a NAS does not carry a printer driver/PPD library it simply creates raw print queues (print queue without filters/drivers, passes incoming data simply through to the printer) and it is expected that one creates a print queue with driver on the client side, as one had a printer which is directly connected to the network.

On a Ubuntu machine there is a program named cups-browsed running which automatically finds remote CUPS servers and printers shared by them and it automatically creates local print queues pointing to these printers so that one can use them easily from the local machine. Usually remote CUPS printers are printers connected to a remote computer using CUPS (usually the case for Linux, Mac OS X, and *BSD operating systems) and sharing its printers. Normally these printers are set up with a suitable driver on the server so that the local queue created by cups-browsed does not need to use a driver by itself and therefore cups-browsed creates raw queues. In addition, these queues are removed again when the remote server or printer disappears or when cups-browsed is shut down.

Now with a NAS using CUPS and sharing raw queues and cups-browsed creating raw queues for all shared CUPS queues which it finds in the network there is no filter or driver from the client through the NAS to the printer and the PDF sent by the application arrives unchanged in the printer and the printer does not understand it. As the queues which cups-browsed generates are removed again when cups-browsed is shut down (for example on reboot) any attempt to "correct" these queues manually only survives until the next reboot.

The bug is in cups-browsed, it should not create local queues pointing to remote raw queues but only to remote queues which have already a driver so that such non-working queues do not appear. This I have fixed in cups-browsed now and this fix will be included in cups-filters 1.0.55.

[Peter Hinch (peterg-1)]

On 30/06/14 15:07, Till Kamppeter wrote:
> What is happening is the following:
>
> Your NAS is a machine running Linux (or some *BSD) and uses CUPS to
> implement the print server functionality. As a NAS does not carry a
> printer driver/PPD library it simply creates raw print queues (print
> queue without filters/drivers, passes incoming data simply through to
> the printer) and it is expected that one creates a print queue with
> driver on the client side, as one had a printer which is directly
> connected to the network.
>
> On a Ubuntu machine there is a program named cups-browsed running which
> automatically finds remote CUPS servers and printers shared by them and
> it automatically creates local print queues pointing to these printers
> so that one can use them easily from the local machine. Usually remote
> CUPS printers are printers connected to a remote computer using CUPS
> (usually the case for Linux, Mac OS X, and *BSD operating systems) and
> sharing its printers. Normally these printers are set up with a suitable
> driver on the server so that the local queue created by cups-browsed
> does not need to use a driver by itself and therefore cups-browsed
> creates raw queues. In addition, these queues are removed again when the
> remote server or printer disappears or when cups-browsed is shut down.
>
> Now with a NAS using CUPS and sharing raw queues and cups-browsed
> creating raw queues for all shared CUPS queues which it finds in the
> network there is no filter or driver from the client through the NAS to
> the printer and the PDF sent by the application arrives unchanged in the
> printer and the printer does not understand it. As the queues which
> cups-browsed generates are removed again when cups-browsed is shut down
> (for example on reboot) any attempt to "correct" these queues manually
> only survives until the next reboot.
>
> The bug is in cups-browsed, it should not create local queues pointing
> to remote raw queues but only to remote queues which have already a
> driver so that such non-working queues do not appear. This I have fixed
> in cups-browsed now and this fix will be included in cups-filters
> 1.0.55.
>
Thank you for your clear and detailed explanation - the NAS does run
Linux. There is one issue about which I'm still unclear. How does my
workround overcome this problem?

I now have a laptop and a Mint/Mate VM both of which now remember the
printer details after reboots, whether or not the printer is up at the
time. It would seem I've persuaded the local software to create a print
queue with local drivers and prevented cups-browsed (which I've
confirmed is running) from "correcting" it on a reboot. I'm puzzled as
to how I've achieved the latter. If the question is irrelevant now
you've identified the cause do feel free to ignore it ;-)

Regards, Pete

[Till Kamppeter (till-kamppeter)]

Note that cups-browsed never "corrects" any print queues which it did not create by itself. It removes all print queues which it created (except for a queue which is set to be the default printer) on shut down or when the printer or server is shut down or disappears for any other reason. With this all manual changes on these print queues get lost. On boot or when the server/printer reappears cups-browsed creates a new print queue.

Queues stay conserved and keep your changes probably because you have set them as default printer or you have created a new print queue (and not modified one which was originally created by cups-browsed).

Print queues created by cups-browsed are marked as such in /etc/cups/printers.conf. They contain the entry "Option cups-browsed true". Note that CUPS does not update printers.conf immediately and can write to it at any time and also cups-browsed does not re-check whether the "Option cups-browsed true" is still there when removing the queue on shutdown. So do not edit printers.conf when at least one of cupsd and cups-browsed is running.

To get a working queue for your printer, ignore the one created by cups-browsed (it will disappear with the next version of cups-filters) and create a new one using the "New printer" button in system-config-printer. This queue will stay conserved through reboot and keep your settings.

[Peter Hinch (peterg-1)]

Thanks for that. Your explanation conforms with my experiences.

Regards, Pete

On 30/06/14 18:08, Till Kamppeter wrote:
> Note that cups-browsed never "corrects" any print queues which it did
> not create by itself. It removes all print queues which it created
> (except for a queue which is set to be the default printer) on shut down
> or when the printer or server is shut down or disappears for any other
> reason. With this all manual changes on these print queues get lost. On
> boot or when the server/printer reappears cups-browsed creates a new
> print queue.
>
> Queues stay conserved and keep your changes probably because you have
> set them as default printer or you have created a new print queue (and
> not modified one which was originally created by cups-browsed).
>
> Print queues created by cups-browsed are marked as such in
> /etc/cups/printers.conf. They contain the entry "Option cups-browsed
> true". Note that CUPS does not update printers.conf immediately and can
> write to it at any time and also cups-browsed does not re-check whether
> the "Option cups-browsed true" is still there when removing the queue on
> shutdown. So do not edit printers.conf when at least one of cupsd and
> cups-browsed is running.
>
> To get a working queue for your printer, ignore the one created by cups-
> browsed (it will disappear with the next version of cups-filters) and
> create a new one using the "New printer" button in system-config-
> printer. This queue will stay conserved through reboot and keep your
> settings.
>

[Launchpad Janitor (janitor)]

This bug was fixed in the package cups-filters - 1.0.55-1

---------------
cups-filters (1.0.55-1) unstable; urgency=medium

  * New upstream release:
    - pdftopdf: Fixed manual duplex by adding a blank page to even
      pages if the total number of pages of the document is
      odd. Otherwise the last page of the document would stay in
      the input tray. This fixes also a side effect as the set of
      even pages reducing to a zero page job if the job consists
      of only one page, making Poppler's pdftops error out
      (LP: #1340435)
    - cups-browsed: Do not create a local queue pointing to a
      remote raw queue (LP: #1335211).

 -- Didier Raboud <email address hidden> Mon, 28 Jul 2014 08:44:07 +0200

[Didier Raboud (odyx)]

@Till: We're having https://bugs.debian.org/756724 as a regression due to this fix; could you comment there?