Bug 393735 - Opening an image from a local folder via Dolphin with a large recent files list is slow
Summary: Opening an image from a local folder via Dolphin with a large recent files li...
Status: RESOLVED WORKSFORME
Alias: None
Product: gwenview
Classification: Applications
Component: general (show other bugs)
Version: 17.04.2
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Gwenview Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-01 17:06 UTC by Don Curtis
Modified: 2018-05-03 21:01 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Don Curtis 2018-05-01 17:06:16 UTC
Select an image file with Dolphin.
Open it.
Wait, and wait, and wait, and wait, until, the image is displayed (at last … ).
Notice that, every other image in that directory has also been opened for inspection …

As an example, a directory with 58 images, total size: 597.6 MB -- 20 Megapixel JPEG camera files: about 25 seconds elapses before the single image selected in Dolphin is displayed -- all the other 57 images are thumb-nailed in the preview pane.

Selecting all 58 images needs about 30 seconds before they're displayed.
Comment 1 null 2018-05-01 19:55:55 UTC
> every other image in that directory has also been opened for inspection
Now sure what you mean by that.

Normally upon clicking on an image in Dolphin, Gwenview should open and display only that image. If you have the Thumbnail bar enabled, afterwards the thumbnails of the other images should be displayed eventually (and cached for later).

Would you be able to record a short screencast/video of what you mean exactly?

> Selecting all 58 images needs about 30 seconds before they're displayed.
Again I'm not really sure what you are trying to do here. Could you give exact steps, and describe what you expected to happen vs. what really happened?
Comment 2 Nate Graham 2018-05-01 20:07:55 UTC
I think he's saying that he thinks that Gwenview took too long to load because it was fetching data for the other images in the folder for the purpose of building thumbnails in the thumbnail bar.
Comment 3 Don Curtis 2018-05-02 07:31:43 UTC
(In reply to Henrik Fehlauer from comment #1)
> > every other image in that directory has also been opened for inspection
> Now sure what you mean by that.
When I open the thumbnail bar, after the required image has opened, all of the other images in that directory are displayed in the thumbnail bar.

> 
> Normally upon clicking on an image in Dolphin, Gwenview should open and
> display only that image. If you have the Thumbnail bar enabled, afterwards
> the thumbnails of the other images should be displayed eventually (and
> cached for later).
It opens and displays the "clicked" (in Dolphin) image only after about 25 seconds. AFAICS, at that point in time the thumbnail bar has been loaded with previews of the other images in the directory.

I normally have the thumbnail bar "closed"/"hidden".
 -- I haven't found any means to 'disable' the thumbnail bar.

> 
> Would you be able to record a short screencast/video of what you mean
> exactly?
I'll see about a series of screenshots.

> 
> > Selecting all 58 images needs about 30 seconds before they're displayed.
> Again I'm not really sure what you are trying to do here. Could you give
> exact steps, and describe what you expected to happen vs. what really
> happened?
Dolphin, directory, <Ctrl-A>, <Return>.
Comment 4 Don Curtis 2018-05-02 07:32:45 UTC
(In reply to Nate Graham from comment #2)
> I think he's saying that he thinks that Gwenview took too long to load
> because it was fetching data for the other images in the folder for the
> purpose of building thumbnails in the thumbnail bar.
Yes, exactly …
Comment 5 Don Curtis 2018-05-02 07:59:26 UTC
Forget the screen shots.

If the Gwenview history has been cleared, it displays an image clicked on in Dolphin within a second or two. Please note that, Gwenview has to be started from the KDE Plasma Application Launcher and the "Recent Folders" also has to be cleared if this performance is to be achieved.

However, given an empty Gwenview history, simply opening an empty Gwenview session via the Plasma Application Launcher takes about 5 seconds to display and a further 20 to 25 seconds before the Menus become active.
Comment 6 Don Curtis 2018-05-02 08:01:09 UTC
I seem to recall that, the newer KDE Plasma versions exhibit a better start-up time -- at least that's what the newest openSUSE Leap 15 comments are saying …
Comment 7 null 2018-05-02 10:30:22 UTC
I'm confused. First you say you have good performance with a clean history:

> If the Gwenview history has been cleared, it displays an
> image clicked on in Dolphin within a second or two
But then you are saying the opposite:

> given an empty Gwenview history, simply opening an empty Gwenview
> session via the Plasma Application Launcher takes about 5 seconds
> to display and a further 20 to 25 seconds

The only explanation I have for this is that you have a slow network folder added to your Places panel. Could you tell us more about where you are opening images from, and what your Places panel contains?
Comment 8 Don Curtis 2018-05-02 10:48:47 UTC
(In reply to Henrik Fehlauer from comment #7)
> I'm confused. First you say you have good performance with a clean history:
> 
> > If the Gwenview history has been cleared, it displays an
> > image clicked on in Dolphin within a second or two
> But then you are saying the opposite:
> 
> > given an empty Gwenview history, simply opening an empty Gwenview
> > session via the Plasma Application Launcher takes about 5 seconds
> > to display and a further 20 to 25 seconds
> 
> The only explanation I have for this is that you have a slow network folder
> added to your Places panel. Could you tell us more about where you are
> opening images from, and what your Places panel contains?
Yes, in the Places panel there're 3 directories on two network servers:
 - 2 SMB shares on an AVM FRITZ!Box DSL Router;
 - one NFS auto-mount point on a QNAP NAS.
Comment 9 null 2018-05-02 11:30:53 UTC
Thanks for the update. Seems we have multiple issues in one bug here:

1. If you have an Autofs mounted NFS share, the Places panel will try to access it, which takes a while due to how the automounting works. I'm lost with the recent bugs reorganization and don't know anymore which bug is _really_ about this exact problem, but starting to browse from Bug 335498 should get you started in the maze of duplicates.

2. Gwenview trying to access images from your history and thus making opening a single image from Dolphin slow. Perhaps those checks can be avoided or done in the background, to prioritize opening of the image itself.

Let's make this bug about the problem #2.

Please don't forget to also tell us from where you were opening the image, i.e. from NFS or SMB, and whether SMB is also automounted or accessed via the smb:// kioslave.
Comment 10 Don Curtis 2018-05-02 12:17:04 UTC
Changed the changed report title:

Original title:
"When opening an image file, the complete contents of the file's directory are also opened"

Was changed to:
"Opening an image from a network folder via Dolphin with a large recent files list is slow"

Is now:
"Opening an image from a local folder via Dolphin with a large recent files list is slow"
Comment 11 Don Curtis 2018-05-02 12:25:05 UTC
(In reply to Henrik Fehlauer from comment #9)
> Please don't forget to also tell us from where you were opening the image,
> i.e. from NFS or SMB, and whether SMB is also automounted or accessed via
> the smb:// kioslave.
The image directory is local on an XFS partition located on the HDD '/dev/sdb'.
The system directory is local on an ext4 partition located on the SDD '/dev/sda'.

The SMB shares are accessed via the smb:// kioslave.
Comment 12 null 2018-05-02 12:28:19 UTC
And what about your recent files list? From which locations did it contain entries from?
Comment 13 Don Curtis 2018-05-02 13:07:27 UTC
(In reply to Henrik Fehlauer from comment #9)
> 1. If you have an Autofs mounted NFS share, the Places panel will try to
> access it, which takes a while due to how the automounting works. I'm lost
> with the recent bugs reorganization and don't know anymore which bug is
> _really_ about this exact problem, but starting to browse from Bug 335498
> should get you started in the maze of duplicates.
Thanks for the tip -- the »expletive deleted« NAS "brick" has removed itself from the LAN.
After shutting it down via the power button and then powering it back on again, guess what?
 ** Gwenview restored to the "normal" «perfect» behaviour!

Many thanks and cheers!!
Comment 14 Don Curtis 2018-05-02 13:13:24 UTC
(In reply to Henrik Fehlauer from comment #12)
> And what about your recent files list? From which locations did it contain
> entries from?
I suspect (believe) that, the recent files list had only local files listed in it but, I could be mistaken.

Thinking about my previous comment, it could be that, due to a DSL issue I experienced earlier this week -- DSL Router power off and then on -- the NAS "brick" didn't re-establish the LAN cable connection.
Comment 15 Don Curtis 2018-05-03 12:21:14 UTC
Given the root cause -- a dead NFS NAS box -- this Bug Report can be regarded as being closed.
Comment 16 null 2018-05-03 21:01:35 UTC
@Don: Thanks for the update, glad it now works for you.

Anyway, I looked more into this, here are my notes:

Gwenview (or any app, really) can hang if a path is mounted, but the underlying server is not accessible anymore. In particular, Gwenview is affected in three places:
- Places panel, when hovering over the entry (i.e. not in Gwenview's, but in the Places panel's code).
- On startup, when trying to access "[Recent Files]" in ~/.config/gwenviewrc (either in Gwenview's code, or in KF5, e.g. KXmlGUI).
- After startup, when cleaning up ~/.local/share/gwenview/recentfolders/gvhistory* (Gwenview's code).

Not sure yet what could be done about those points, though.