GNOME Bugzilla – Bug 786794
Print dialogue has a printer called "printer"
Last modified: 2018-05-02 18:56:05 UTC
And that "printer" isn't a printer that I added, and is always shown as "rejecting jobs". attachment 358356 [details] shows a screenshot of that dialogue. The ML-2950 printer is the only printer I added to my setup, and it's inaccessible (as expected, after losing its settings).
for me, it is called "print" but yes, rejecting jobs
What does return "lpstat -t" for this printer? Is it listed there?
(In reply to Marek Kašík from comment #2) > What does return "lpstat -t" for this printer? Is it listed there? $ lpstat -t scheduler is running no system default destination device for ML-2950: dnssd://Samsung%20ML-2950%20Series%20(SEC001599A712EA)._printer._tcp.local/ ML-2950 accepting requests since Thu 24 Aug 2017 20:16:06 CEST printer ML-2950 is idle. enabled since Thu 24 Aug 2017 20:16:06 CEST The printer is not responding. I have no idea if it's "listed there" as I can't parse that output.
It is not listed there so it is probably a printer shared via DNSSD or via Google Cloud Print. Regarding the DNSSD, could you send me what "avahi-browse _ipp._tcp -r" returns (if it is empty, try _ipps._tcp or _printer._tcp services)? In the case of Google Cloud Print, could you turn off printers feature in online accounts panel in g-c-c (if enabled) to see whether the printer disappears?
$ avahi-browse _ipp._tcp -frt + wlp2s0 IPv4 Samsung ML-2950 Series (SEC001599A712EA) Internet Printer local = wlp2s0 IPv4 Samsung ML-2950 Series (SEC001599A712EA) Internet Printer local hostname = [SEC001599A712EA.local] address = [192.168.0.25] port = [631] txt = ["Staple=F" "Sort=F" "Scan=F" "Punch=0" "PaperCustom=T" "Duplex=T" "Copies=T" "Color=F" "Collate=F" "Bind=F" "URF=W8,RS600,IS1,CP1,IFU0,PQ4,OB1,DM1" "UUID=16a65700-007c-1000-bb49-001599a712ea" "MDL=ML-2950 Series" "MFG=Samsung" "usb_CMD=MFG:Samsung;CMD:SPL,PCL6,URF,PIC,BDN,FWV,DCU,EXT;MDL:ML-2950 Series;CLS:PRINTER;MODE:SPL3,R000105;URF:W8,RS600,IS1,CP1,IFU0,PQ4,OB1,DM1;" "usb_MDL=ML-2950 Series" "usb_MFG=Samsung" "adminurl=http://192.168.0.25" "pdl=application/octet-stream,application/PCL,application/vnd.hp-PCL,application/vnd.hp-PCLXL,application/x-QPDL,text/plain,image/urf" "product=(Samsung ML-2950 Series)" "ty=Samsung ML-2950 Series" "priority=51" "qtotal=1" "note=" "rp=ipp/printer" "txtvers=1"] $ avahi-browse _ipps._tcp -frt $ avahi-browse _printer._tcp -frt + wlp2s0 IPv4 Samsung ML-2950 Series (SEC001599A712EA) UNIX Printer local = wlp2s0 IPv4 Samsung ML-2950 Series (SEC001599A712EA) UNIX Printer local hostname = [SEC001599A712EA.local] address = [192.168.0.25] port = [515] txt = ["Staple=F" "Sort=F" "Scan=F" "Punch=0" "PaperCustom=T" "Duplex=T" "Copies=T" "Color=F" "Collate=F" "Bind=F" "MDL=ML-2950 Series" "MFG=Samsung" "usb_CMD=MFG:Samsung;CMD:SPL,PCL6,URF,PIC,BDN,FWV,DCU,EXT;MDL:ML-2950 Series;CLS:PRINTER;MODE:SPL3,R000105;URF:W8,RS600,IS1,CP1,IFU0,PQ4,OB1,DM1;" "usb_MDL=ML-2950 Series" "usb_MFG=Samsung" "adminurl=http://192.168.0.25" "pdl=application/octet-stream,application/PCL,application/vnd.hp-PCL,application/vnd.hp-PCLXL,application/x-QPDL,text/plain,image/urf" "product=(Samsung ML-2950 Series)" "ty=Samsung ML-2950 Series" "priority=49" "qtotal=1" "note=" "rp=auto" "txtvers=1"] I don't have any Google Cloud Print setup, never did.
Maybe it is the same printer. Show me output of this "GTK_DEBUG=printing gtk3-demo | grep "Found printer"" please. Just run the printing demo there. It should show us devices of the listed printers.
(In reply to Marek Kašík from comment #6) > Maybe it is the same printer. Show me output of this "GTK_DEBUG=printing > gtk3-demo | grep "Found printer"" please. Just run the printing demo there. > It should show us devices of the listed printers. CUPS Backend: Found printer ipp://localhost/printers/ML-2950 CUPS Backend: Found printer ipp://192.168.0.25:631/ipp/printer Yep, both of those are supposed to be the same. I'm guessing one discovered through mDNS, the other through CUPS browsing?
The "ML-2950" is the one you've installed and the "printer" is discovered by CUPS backend in Gtk+ via mDNS. I'll look at whether and how we recognize duplicates there. Thank you for the info.
Created attachment 358775 [details] [review] Don't show duplicate printers Looking at the code, we are checking for duplicates by name only. The attached patch checks UUIDs of printers installed on local CUPS (by extracting them from device-uri) and compares them with UUIDs of printers being shared via DNSSD. But not all printers provides UUID via DNSSD, especially using the _printer._tcp service. This patch will not help in your case because the device-uri of the printer installed on your local CUPS doesn't contain the UUID. I'll look how is it possible that the _printer._tcp service was selected over the _ipp._tcp when the printer was installed yet.
(In reply to Marek Kašík from comment #9) > I'll look how is it possible that the _printer._tcp service was > selected over the _ipp._tcp when the printer was installed yet. This happened because the printer itself assigned higher priority (49 vs 51) to the "_printer._tcp" service. Nothing we can do about.
Review of attachment 358775 [details] [review]: lets land this
Comment on attachment 358775 [details] [review] Don't show duplicate printers Thank you for the review. I've pushed the patch into gtk-3-22 and master branches. I'll keep this bug open since the original bug was not fixed yet. I'm not sure how to fix it since it seems that CUPS/Avahi does not give as enough info to recognize such duplicates. I would not like to compare host names because sometime I get FQDN and sometimes IP addresses. The same happens with service names because of escaping of characters.
https://bugs.archlinux.org/task/57304 The not gtk+ Chrome print dialog shows these printers correctly. Chrome uses the libcups interface which scans for ipp printers. Can ipp scanning be moved to CUPS so we can disable this workplace hostile feature Bug 738431 in one place? For my 50+ printers the print dialog was unusable. I went through and shut off IPP and WSD for every printer that allowed it. If you want some bigger lists I can turn ipp back on in all my printers. ipv6 complicates matters since the same printer can now report two addresses. % GTK_DEBUG=printing gtk3-demo | grep "Found printer" CUPS Backend: Found printer ipp://localhost/printers/HPM401 CUPS Backend: Found printer ipp://[fd00::111]:631/printers/P2035 CUPS Backend: Found printer ipp://[fd00::1be]:631/ipp/printer CUPS Backend: Found printer ipp://128.0.0.112:631/ipp/print % GTK_DEBUG=printing gtk3-demo | grep "Found printer" CUPS Backend: Found printer ipp://localhost/printers/HPM401 CUPS Backend: Found printer ipp://128.0.0.4:631/printers/P2035 CUPS Backend: Found printer ipp://128.0.0.92:631/ipp/printer CUPS Backend: Found printer ipp://128.0.0.119:631/ipp/print cups fd00::111 128.0.0.4 Linux CUPS shared printer ipp fd00::1be 128.0.0.92 HP LaserJet 400 color M451nw ipp 128.0.0.119 Brother MFC-J870DW ipp 128.0.0.112 Brother MFC-J875DW There are 9 P2035 printers shared by 128.0.0.4. No autodetect list ever contains more than one. Dup elimination by name would work so long as you use something we can set. For printers this is the Bonjour/Airprint/ipp name. For CUPS this is the description. CUPS uses description+location. As you can see multiple printers are coming up as "printer". It's Russian roulette with printers! Now I know how to identify the source of the cryptic names in the dialog box. The dynamically added printers never work. In Chrome they select and [Print] just fine but nothing comes out. Selecting them in Firefox locks up Firefox and crashes some printer models off the network. I'm sure there's something I could install to make it work but I just want them to go away. > higher priority (49 vs 51) to the "_printer._tcp" This is settable in the printer. HP calls this option "Bonjour Highest Priority Service".
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/887.