[SOLVED] xsane scanning for devices appears to hang

[mla]

I have an HP4620 network (wifi) printer/scanner/copier. It works fine as a printer, but of late (since Mageia 5 upgrade?) trying to use it as a scanner no longer works, which it used to. Xsane gives the small window saying "Scanning for devices" and just sits there indefinitely. I can connect to the printer vie the HTTP niterface and it shows no anomalies -- and as already noted, printing works just fine, so it is not a matter of network connectivity.

I have tried to go to the control centre to configure the scanner (which usually is not necessary, having configured the printer) and that also sits there saying (in a separate small window "Searching for configured sacnners...".

Any suggestions, anybody?

[mla]

Just discovered... If I try to set up scanner via the control centre without trying to run xsane first, it does not hang, but tells me "There ar no scanners found which are available on your system". It then gives options for "Search for new scanners" (same result) and "Add a new scanner". Trying the latter option presents me with a list of vendors. Selecting HP gives a list of options of which the only applicable is "Most HP OfficeJet, LaserJet and PSC multi-function peripherals. Well my 4620 is an "OfficeJet", but selecting this option and clicking on OK, results in

The Hewlett-Packard Most HP OfficeJet, LaserJet, and PSC (Printer/Scanner/Copier) multi-function peripherals must be configured by system-config-printer.
You can launch system-config-printer from the %s Control Center in Hardware section.

So I head to the hardware section, but that already has my HP OfficeJet 4620 configured! Which leaves me stuffed.

And in any case, there is something very wrong if xsane hangs (needs kill -9 to be rid of too!) and that somehow makes the ontrol centre's scanner search to heng too (also needs kill -9).

[doktor5000]

Dumb question, that printer is configured via wifi or directly connected to you box via USB currently?

If you use hp-setup to configure the scanner, does that produce different results? Maybe try the hints from http://hplipopensource.com/node/365
This is also suggested by https://wiki.archlinux.org/index.php/Sa ... er.2Ffaxes

Alternatively, if you use hp-scan, what are the results?
And please try to attach or post the output of hp-doctor

[mla]

Dear Doctor, your questions are never dumb. The printer is strictly wifi only, no other interfaces. More to the point, your suggestion to use hp-setup (a tool new to me), did the trick. Interestingly, the printer description it created differs from the one created via the contol centre -- presumably in a crucial manner. The control centre gave URI as "socket://192.168.1.65:9100", whereas hp-setup made it "hp:/net/Officejet_4620_series?ip=192.168.1.65". Make and model they agree on: "HP Officejet 4620 Series, hpcups 3.14.6".

I've just checked on a fully up-to-date Mageia 4 and it has exactly the same problem of being unable to detect the scanner, which certainly did not use to be the case. I'll try to work out when was the last time we scanned something, but it would have been months (but less than a year).

Anyway, thanks for your help, as ever! It's the kind of support level unheard from commercial OS vendors (no names named! )

[doktor5000]

hp-setup is the tool that is provided by hplip to setup your HP device. There are some more of those, all begin with hp-

The problem was maybe introduced with one of the recent hplip upgrades for Mageia 4, and how the same issue is also present in the Mageia 5 version.

Sadly I've got no access to an hp multifunction device to test and debug this whole issue myself, as our hplip integration is still a troublesome area :/

[mla]

"Some more" being 34 altogether. Agreed, your suggestion as to the problem's history seems to be the only one that fits facts. I ought to be upgrading Mageia on my laptop (still version 3!), which is really a Win7 machine, only used on rare occasion when I need to test something on Windows. So I could freely experiment there, if you tell me exactly what you want to try.

[mla]

Well, this is very odd... I have upgraded to Mageia 5 on my Lenovo laptop and configured the printer using the control centre, which created the "socket://192.168.1.65:9100" entry for it -- the one that fails to work on my desktop. Trouble is, here xsane is entirely happy to detect the printer using this antry. Further trouble is, having detected the scanner it fails to do any scanning -- just produces the error message "Failed to start scanner: invalid argument".

But if I define the printer via hp-setup, all works on the laptop too.

[doktor5000]

So I could freely experiment there, if you tell me exactly what you want to try.

I want to try to simply make it work without issues, and I can't tell you exactly what to do - as I would first have to see
what is wrong with local USB printer&scanner setup via system-config-printer, and then compare that to what hp-setup does.
Rinse&repeat for wifi access. Then fix it.

[mla]

Well, make it work without issues is obviously the aim. But my question really is how would you go about seeing what is wrong? I am of the old Unix school, hoping (sometimes in vain these days) to be able to compare various ASCII config files themselves, rather than relying on what some GUI front-end chooses to show me. In this case it would seem that that one would be starting with /etc/printcap, /etc/cups/printers.conf, /etc/cups/ppd/Officejet_4620.ppd.

The only differences are (1) the URI is different in /etc/cups/printers.conf, as already reported above, and (2) the respective .ppd files in /etc/cups/ppd give cupsVersion as 1.5 in the one created by the control centre (i.e. by system-config-printer?), and 2.0 in the one created by hp-setup. The installed cups is, of course, 2.0. But just fixing these differences and restarting cups does not cure the problem. Beyond that I don't know where to look.

[mla]

Ah... Wrong. Fixing the URI in printers.conf does the trick. It's just that once xsane is stuck it is stuck. If I reboot the machine, given the change in the URI, xsane behaves itself. So that's would appear to be the only thing that *really* needs fixing. Just how hp-setup knows to use "Officejet_4620_series" (rather than "Officejet_4620") in that URI, I do not know, but the rest of it is self-explanatory.

Mind you, Cups version 1.5 in the ppd file created by the control centre is clearly wrong too, but does not seem to matter.

[doktor5000]

Well, make it work without issues is obviously the aim. But my question really is how would you go about seeing what is wrong? I am of the old Unix school, hoping (sometimes in vain these days) to be able to compare various ASCII config files themselves, rather than relying on what some GUI front-end chooses to show me. In this case it would seem that that one would be starting with /etc/printcap, /etc/cups/printers.conf, /etc/cups/ppd/Officejet_4620.ppd.

Yeah, I'd probably start with a vanilla hplip install directly from http://hplipopensource.com/hplip-web/gethplip.html and for the installation see http://hplipopensource.com/hplip-web/in ... other.html
You can peek at http://hplipopensource.com/hplip-web/in ... driva.html but you would have to compare thoroughly.

When that's done, compare the installation via hp-setup in /etc/cups/printers.conf and the PPDs to the one done via system-config-printer by diffing them. Reset /etc/cups/printers.conf in between.
Then rinse and repeat the same process with the Mageia hplip packages.

That's how I'd do it. And then we have to take into account the changes we do in our system-config-printer packages, by trying the vanilla version: http://cyberelk.net/tim/software/system-config-printer/

FWIW, can you please post the 2 different URIs you obtained from hp-setup vs. system-config-printer please?

[mla]

FWIW, can you please post the 2 different URIs you obtained from hp-setup vs. system-config-printer please?

I did, in the thread above. System-config-printer gives

Code: Select all

socket://192.168.1.65:9100

which xsane does not like (but printing rather than scanning works fine with it). OTOH hp-setup gives

Code: Select all

hp:/net/Officejet_4620_series?ip=192.168.1.65

Replacing the "socket:" one with the "hp:" one in printers.conf cures the problem for scanning and printing continues to work too.

Wouldn't the most robust solution simply consust of system-config-printer invoking hp-setup if it decides that it is dealing with an HP device?

[doktor5000]

Wouldn't the most robust solution simply consust of system-config-printer invoking hp-setup if it decides that it is dealing with an HP device?

Yep, was proposed already via e.g. https://bugs.mageia.org/show_bug.cgi?id=1454
Feel free to provide a working patch for system-config-printer and I'll see to upload it.

[mla]

Hmmm... I'll have a look, but python is not as yet one of my languages.

[mla]

... and it's intertwined with Gtk. I can see that "simply invoke hp-setup" isn't that simple.

However, I can offer a trivial change which would improve things. The *actual* problem is that system-setup-printer presents the user (me, for example) with a set of incomprehensible options, defaulting to the first one. For an HP printer this happens to be JetDirect, followed by IPP, followed by (after a pause!) by hp:/net... (the correct URI!).

Two issues here. Firstly, as a naive user, not understanding what this is all about, I trust the default to be a sensible one, which it happens not to be. This can be, I think, very easily fixed by re-ordering probe types defined on line 245 of probe_printer.py and putting probe_hplip top, before probe_jetdirect.

The other problem arises, as in my case, when the user clicks on Network printer -> Find Network printer, at which point he appears to be prompted for an IP address of the printer. In the meantime, the network scan is being done, which fails (due to firewalls, I think) and a list of generic options is offered, headed with (and defaulting to) JetDirect. Re-scan based on the ip-address take a while and in the meantime, the user (me) click on Forward, just as the hplip entry pops into the list of options. That's just a problem with user interface, because it is entirely unclear what is happening or why. Re-ordering the probes won't solve this, but will make it a bit more likely that the hplip URI will get discovered and defaulted to. Anybody still complaining can be told not to be too hasty. Not that I would advovate that in preference to fixing the user interface -- perhaps the system could pop up a message "Probing... please wait". But my knowledge of python/Gtk is way-insufficient to even suggest how this should be done.

Over to you?

[doktor5000]

Sorry, I don't even have a printer to test :/
But feel free to add that information to a new bugreport against system-config-printer.
For the last few, phillipem did some changes to the python backend for network printer detection, see the one mentioned in your other thread: viewtopic.php?f=24&t=9986
But maybe those slight detection change proposals (and especially the thing about "scanning - please wait") can also be proposed upstream at https://github.com/twaugh/system-config-printer/issues IMHO.

There has even been another Mageia user who reported https://github.com/twaugh/system-config ... r/issues/5

[mla]

OK, I've added a "seconded!" comment to the proposal on github.

Problem is, my discovery concerning the firewall complicates things, because when the printer is auto-detected the the GUI interface behaves quite differently -- and it becomes even more difficult for a naive user to do other than follow defaults.

And BTW, perhaps one should also ask the other question: why is xsane failing to work with the standard JetDirect URI, when all printing is quite happy with it?

[doktor5000]

And BTW, perhaps one should also ask the other question: why is xsane failing to work with the standard JetDirect URI, when all printing is quite happy with it?

Sorry no clu - you might find an answer in the sane project archives, or ask them this question.

[mla]

Two issues here. Firstly, as a naive user, not understanding what this is all about, I trust the default to be a sensible one, which it happens not to be. This can be, I think, very easily fixed by re-ordering probe types defined on line 245 of probe_printer.py and putting probe_hplip top, before probe_jetdirect.

This partial solution has now been, I believe, accepted and implemented upstream.

OTOH the idea of handing all HP devices to HPLIP appears to have the aerodynamic qualities of a lead balloon.