Bug 75472 - List of printers is only read at app launch time, never re-read, jobs fail silently
Summary: List of printers is only read at app launch time, never re-read, jobs fail si...
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
4.3.0.0.alpha0+ Master
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-24 21:46 UTC by Alex Korobkin
Modified: 2016-10-10 10:22 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Korobkin 2014-02-24 21:46:55 UTC
Problem description: 
It seems LibreOffice only reads the list of printers when it starts, and keeps the connection live all the time. If the CUPS printserver restarts, or if the laptop with LibreOffice is moved between the networks, LibreOffice cannot print anymore until relaunched. This is quite serious inconvenience for users with laptops. 

Steps to reproduce:
1. Open new empty document in LibreOffice Writer
2. Print it
3. Restart CUPS on the printserver (sudo service cups restart)
4. Try printing the document again

Current behavior:
LibreOffice silently fails to print without showing any error message. 

Expected behavior:
Ideal: re-read the list of printers when Print dialog is shown, print the document. 
Less ideal: show error message that it couldn't print. 

              
Operating System: Ubuntu
Version: 4.3.0.0.alpha0+ Master
Comment 1 tommy27 2014-06-07 04:42:01 UTC
hi did you try with a recent 4.3 beta2 build? is issue still there?
Comment 2 Alex Korobkin 2014-08-28 15:24:21 UTC
Tested with recently released 4.3.1.2, the bug is still there.
Comment 3 Buovjaga 2014-11-13 11:04:09 UTC
Could not reproduce silent error or any error for that matter.

Ubuntu 14.10 64-bit Version: 4.3.3.2
Build ID: 430m0(Build:2)

and

Version: 4.4.0.0.alpha2+
Build ID: 5bff4b016c4b44f4123e0e6a4fd4c0c4dc0cfa2d
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-13_00:14:29
Comment 4 Alex Korobkin 2014-11-13 17:12:12 UTC
Looks like it handles it better with this version. 

It still cannot hanlde the situation when printserver changes via /etc/cups/client.conf:

1. Add your printserver to /etc/cups/client.conf using

ServerName yourprintserver.tld

2. Check the list of printers: lpstat -a
3. Start libreoffice, check the list of printers
4. Edit /etc/cups/client.conf,

ServerName anotherprintserver.tld

5. Check the list of printers: lpstat -a
Should see printers from another printserver

6. In currently opened LibreOffice check the list of printers:

You will see the same old list of printers. 


This scenario might look unusual, but it helps people who move between buildings or floors with their laptops. They might change client.conf manually, or ServerName might point to a cname that resolves to a different server in each network. 

lpstat -a and GTK dialog always correctly show the printers. LibreOffice insists on showing the printers from the original printserver that was there when it started.
Comment 5 tommy27 2015-06-21 19:00:58 UTC
hi, would you please give an update of the bug current status with latest LibO 4.4.x releases?
Comment 6 Xisco Faulí 2016-09-11 13:22:25 UTC Comment hidden (obsolete)
Comment 7 Xisco Faulí 2016-10-10 10:22:53 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-20161010