Bug 132129 - slow startup on windows in connection with shared printers if the sharing pc is turned off
Summary: slow startup on windows in connection with shared printers if the sharing pc ...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.4.2.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Network
  Show dependency treegraph
 
Reported: 2020-04-15 17:21 UTC by t-mor
Modified: 2022-06-21 17:09 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description t-mor 2020-04-15 17:21:17 UTC
Description:
The problem occurs if you open presentations on a windows pc that has a configured connection to a shared usb-printer of another windows-pc. If this usb-printer-pc is turned off, the startup hangs (seems to wait for a timeout) for a long time (minutes).
During the use (of opened presentations) the problem repeats from time to time. At present, I couldn't find the specific reason for the latter one.

If you open multiple documents it becomes worse. The document-windows appear to check the network connection independently, but each of them blocks all libreoffice-windows so that finally all opened presentations do not respond and inputs are impossible. The more documents are opened, the shorter is the time in which work is still possible.

As soon as the PC (that is sharing it's USB printer) is started the startup time is normal as well as pending startups will be quickly continued.

Attention:
Apparently, it is not the printer that has to be activated, but the PC that shares it. Thus, it is enough to start the sharing pc.


Steps to Reproduce:
1. connect your pc (sw connect via network) to a shared usb-printer of another pc 
(save the user credentials so that it would be possible to print after reboots in order not to have to enter the access data again.)

2. print an impress slide on this printer so that it is the last printer you've used

3. save your presentation

4. turn off the pc with the usb-printer

5. turn off the usb-printer

6. reboot your pc

7. open your presentation ... and wait a long time because it hangs
 (I assume impress trys to find the pc with the printer until a network timeout)


X. This not only happens on startup, but also during use.
 (I assume in the case of auto-save or something else)


Actual Results:
- slow startup
- hanging impress

Expected Results:
- normal startups
- no hangs depending on whether the PC of a shared printer is active or not
- no hangs during use


Reproducible: Always


User Profile Reset: No



Additional Info:
-
Comment 1 t-mor 2020-06-05 17:06:45 UTC
Of course, the problem arises not only when the PC that is sharing the USB printer is turned off, but also when you are connected to other networks and therefore the printer cannot be found. Thus, Notebook users are more likely to be affected.

Of course, you could remove the shared device every time you don't need the printer, want to change the network, or before you turn off the sharing PC ... and reconnect when it's needed.


In the meantime, I've found a bad but simpler workaround for my notebook.

The problem doesn't occur if you stop the printer-queue service. So, I switched the service from "auto" to "manual". Since I only print a little, this default setting is ok for me until the problem is resolved.

At the moment, I only have to start the printer-queue service if I want to print and by default everything is ok after starting the notebook.
Yes, it's not nice, but better and faster than the other options.
Comment 2 t-mor 2020-10-11 16:46:47 UTC
I tested it again with release 7.0.2 and the problem is still there.
Comment 3 Xisco Faulí 2021-02-15 18:12:07 UTC
A new major release of LibreOffice is available since this bug was reported.
Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Comment 4 t-mor 2021-03-27 13:20:23 UTC
I tested it again with 7.1.1.2.

The problem is still there, but it's not as bad as it was before.

The good news: With 7.1.1.2 there is a pause of 10 to 15 seconds before opening continues, (if the printer-queue service is running as described above).

Still, as soon as I stop the service, the problem is gone. So, the workaround is still possible.
Comment 5 Telesto 2021-03-28 08:07:02 UTC
(In reply to t-mor from comment #4)
> I tested it again with 7.1.1.2.
> 
> The problem is still there, but it's not as bad as it was before.
> 
> The good news: With 7.1.1.2 there is a pause of 10 to 15 seconds before
> opening continues, (if the printer-queue service is running as described
> above).
> 
> Still, as soon as I stop the service, the problem is gone. So, the
> workaround is still possible.

I do believe this being an true issue. There floating few more of these around. LibreOffice tendency to ask to printer for information (for example paper size) at impossible places (without exactly knowing why it should be relevant)

It a Windows issue. Has to do with Network. And probably type of printer/driver. My hypothesis LibreOffice is asking the printer for information.. But the response isn't immediately given (driver design/issue or network issue are whatever). So 12 seconds might be kind of time out kicking in -> so LibreOffice going ahead without that info.

I kind of interested how this: https://gerrit.libreoffice.org/c/core/+/107554 pans out. It might/could be solving this. 

Still think printer code is triggered at oddly places, but less of a problem if goes unnoticed (because there is no delay). Except delay lovely excuse to get this designed better in general :P. But lets wait for commit 107554
Comment 6 Carl Michal 2021-09-05 05:27:05 UTC
I saw a very similar issue. I'd configured a windows print queue (win 10) to send PDF's to a cups server (hosted on linux). When the windows box was on a different network and couldn't see the cups server, LO hangs for a couple of minutes when opening the first file. When I deleted the print queue, the problem disappeared. That's with LO 7.2.0.4.

It looks like at least some of the discussion in bug #42673 overlaps with the issue here?
Comment 7 Xisco Faulí 2022-05-02 12:05:08 UTC
A new major release of LibreOffice is available since this bug was reported.
Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Comment 8 t-mor 2022-05-15 13:04:15 UTC
Tested again: with 7.3.3

The problem is still there, and it's worse than last time.
Now, it's a reproducible 30s delay when the printer queue service is running but the sharing pc with it's usb-printer isn't present.


btw. I'm switched to Windows 11. As expected, the problem remains.

Notice: For reproducible tests the printer should be selected as standard printer. So, uncheck the "Let windows manage my default printer" option.



schematic representation:

----------------------------------------------------
- PC-host with USB-Printer (gives a network share) -
----------------------------------------------------
  |
  |
  x (Libreoffice startup troubles for PC-mobile
  |  if the sharing PC-host isn't active or reachable)
  |
  |
----------------------------------------------------------
- PC-mobile with LibreOffice is using the shared printer -
----------------------------------------------------------


A typical error scenario is that you are occasionally on the go with PC-mobile and then cannot reach the pc-host. As soon as you stop the printer service, the problem is gone. So, a workaround exists, but I think it should work without it.
Comment 9 Harry Jack 2022-06-21 10:59:49 UTC Comment hidden (spam)