Hallo, nur als kleiner Hinweis vorweg: Der Text im Subject ist wenig geeignet, um wohlwollende Hilfe auf freiwilliger Basis zu erhalten (unsachlich, Tippfehler, Ausrufezeichen). On Oct 20 12:40 Kyek, Andreas, VF-DE wrote (shortened):
Ich hatte diese "Anschubsen" müssen mit hplip eigentlich immer. Das _könnte_ daran liegen, das mein Drucker fast immer aus ist; wenn jemand druckt wird der Drucker meist erst später irgendwann eingeschaltet wenn man die Ausdrucke abholen will (zwischen Wohnzimmer und Drucker liegt eine Etage!).
Alle diese Probleme verschwinden, wenn ich von hplip auf "socket" direkt umstelle.
Siehe "What is a CUPS backend and how does it work?" in http://en.opensuse.org/SDB:CUPS_in_a_Nutshell Vergl. auch https://bugzilla.novell.com/show_bug.cgi?id=631266 Anscheinend gibt das "hp" Backend zumindest bei HP Netzwerkdruckern (oder vielleicht nur bei dem speziellen Modell) zu schnell auf, vergl. https://bugzilla.novell.com/show_bug.cgi?id=337794#c16 Für solche Backends kann man normalerweise als Workaround das "beh" Backend (im Paket foomatic-filters dabei) zwischenschalten z.B. mit der YaST Druckerkonfiguration via "Connection Wizard" (ich weiß jetzt nicht, wie der in der deutschen Übersetzung heisst). Aber gemäß http://www.linuxfoundation.org/collaborate/workgroups/openprinting/database/... ------------------------------------------------------------------ beh works with every backend except the hp backend from HPLIP. If beh is used with the hp backend, the HP Toolbox will not find the printers any more. ------------------------------------------------------------------ Also zu http://hplipopensource.com/hplip-web/support.html und den Autoren von HPLIP melden, dass ihr "hp" Backend zumindest bei HP Netzwerkdruckern zu schnell aufgibt. Siehe insbes. https://bugzilla.novell.com/show_bug.cgi?id=337794#c16 -------------------------------------------------------------------- As long as the backend cannot establish a communication with its recipient, it cannot cause damage when it loops infinitely and retries again and again (with a reasonable sleep time between each retry). ... I think that the backends should be more robust against possibly transient errors. I would like to suggest that when there is a chance that an error condition goes away while the backend is about to establish a communication with its recipient, it should loop infinitely and retry again and again. Of course with a reasonable sleep time between each retry preferably with additional options via DeviceURI so that expert users can specify for each queue how many retries are done and what the sleep time is - just like the options of the "beh" backend error wrapper... And with reasonable stderr-messages so that user is continuously informed for each re-try what goes on (e.g. "123th re-try to connect to USB printer ACME FunPrinter 1000: no response"). If the user doesn't like it, he can simply cancel his print job. In contrast only the admin can re-enabe a queue. But if there is a communication error while the backend sends data, it should exit with exit code 3 (CUPS_BACKEND_HOLD) so that the partially printed job is neither lost nor automatically re-printed. The user can then decide what to do with his partially printed job. -------------------------------------------------------------------- Ich habe das den Autoren von HPLIP schon vor Äonen gemeldet, doch nur hinreichend viele (höfliche) Beschwerden von echten Kunden können große Firmen in Bewegung versetzen. Es muß bei denen schon an irgendeiner schmerzempfindlichen Stelle "pieksen" und am meisten schmerzt große Firmen (drohender) Geldverlust weil die im wesentlichen nur Geld messen und in Geld "denken" können. Gruß Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex