Bug 416937

Summary:	Dolphin occasionally takes 1 minute to start
Product:	[Applications] dolphin	Reporter:	tagwerk19
Component:	general	Assignee:	Dolphin Bug Assignee <dolphin-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	gfew3vhy, kfm-devel, meven29, nate
Priority:	NOR
Version:	19.12.1
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	ZIP of screen recording, strace showing delay, strace showing normal operation ZIP of equivalent behaviour with gwenview (traces) ZIP of equivalent behaviour with gwenview (screen recording)

Description tagwerk19 2020-01-30 07:08:10 UTC

Created attachment 125538 [details]
ZIP of screen recording, strace showing delay, strace showing normal operation

SUMMARY:

    At times Dolphin is very slow to start (and then to navigate). Whether launched from a link or the command line, it takes about a minute to start properly. The majority of the time it starts within a couple of seconds, then for no discernable reason it takes 30 seconds for Dolphin to appear on screen and another 25/30 seconds for the panel to be populated (see attached screen recording). This behaviour persists for some minutes and then goes back to normal. If you log out and back in again, the problem goes away. 

STEPS TO REPRODUCE:

    No fixed or repeatable way of reproducing this.

    Tested in a KVM guest under a 'test' username with a small number of user files. No mounts of other filesystems, local or remote. No tags defined. In this configuration, actively trying to provoke the bug, it happens one or twice a day.

OBSERVED RESULTS:

    If watching the process list, when Dolphin is launched, /usr/bin/dolphin runs. After 30 seconds Dolphin appears on screen and a set of files.so and tags.so processes appear. Than after a further 25/30 seconds the contents of the folder is displayed

    Collect more information with strace:

        strace -o trace -t -f /usr/bin/dolphin /home/test/Picture

    shows sequences of ETIMEDOUT errors (with 5 second delays). The strace is also attached (and a trace with normal operation)

    Seems independent of baloo (or at least purging and reindexing does not make a difference) 

SOFTWARE/OS VERSIONS

    Dolphin 19.12.1
    from Neon 5.17

    KDE Plasma 5.17.5
    KDE Frameworks 5.66.0
    Qt 5.13.2

ADDITIONAL INFORMATION

    In relation to https://bugs.kde.org/show_bug.cgi?id=409574; read up that one while trying to work out what was happening here. No mention in this instance of trying to open LC_SCRIPTS. Regional settings were left 'as is' as en_US...

Comment 1 Nate Graham 2020-01-31 19:57:17 UTC

Please add findings to Bug 348521, thanks!

*** This bug has been marked as a duplicate of bug 348521 ***

Comment 2 Christoph Feck 2020-01-31 22:07:15 UTC

Bug 348521 was initially reported for the "1 second lag", but got comments about much longer lags, similar to the one reported as bug 409574.

Comment 3 tagwerk19 2020-02-02 10:36:12 UTC

Tried clearing the limit on the Wastebin size (as mentioned in a KDE thread, err, somewhere...):

    still occasional instances of delay, no difference

Moved the VM (by copying the qcow2) to a different KVM host

    still occasional instances of delay *

Built new clean Neon 5.17 VM. Updated to the Dolphin 19.12.1, Neon 5.17.5 level...

    still occasional instances of delay *

Not able to say whether the issue occurs "as often" in these asterisked tests, potentially (gut feeling) it is less frequent.

Comment 4 tagwerk19 2020-02-02 11:13:02 UTC

Created attachment 125611 [details]
ZIP of equivalent behaviour with gwenview (traces)

Comment 5 tagwerk19 2020-02-02 11:15:00 UTC

Created attachment 125612 [details]
ZIP of equivalent behaviour with gwenview (screen recording)

Comment 6 tagwerk19 2020-02-02 11:17:17 UTC

Cross check with https://bugs.kde.org/show_bug.cgi?id=411196

    Gwenview showed a delay launching and subsequent delay displaying the image.

    Not able to close Gwenview (had to terminate)

    When Gwenview showed this behaviour, a following run of Dolphin showed the same.

Captured strace with

    strace -o typescript -t -f /usr/bin/gwenview /home/test/Pictures/A.png

Three traces attached in the zip; the first of gwenview launching, the next of dolphin, the last of gwenview again. The high CPU use for Xorg seen in the screen recording looks like it is the result of the screen recording. The third trace was done without screen recording and no extra CPU load. The third trace also shows a "Bad File Descriptor" loop after trying to close gwenview...

Not all such instances are persistent, seen cases where gwenview is slow and a subsequent run, of gwenview or dolphin, is fine.

Comment 7 Méven Car 2021-04-15 05:37:47 UTC

*** This bug has been marked as a duplicate of bug 409574 ***

Comment 8 tagwerk19 2021-04-15 06:50:48 UTC

I don't think I've seen this behaviour for months

In the latter times I saw it (anecdotal recollection, I've got nothing written down), I associated it with klipper/clipboard issues. Nothing to do with KDEConnect in my case, but text being "clipped" in different KVM guest. The "go to" solution became deleting the entire clipboard history...

I do still see clipboard problems but no longer the "30 second/1 minute pause"

Comment 9 tagwerk19 2021-04-15 10:09:18 UTC

The link to KDEConnect was discussed in Bug 411196