We has our suspicions too, Preciousss.
Sneaky little Hobbitses! Tricksy little Hobbitses!
We has our suspicions too, Preciousss.
Sneaky little Hobbitses! Tricksy little Hobbitses!
Thought experiment:-
/usr/share/icons
and the specific subfolder is dependent upon which theme is used.
755
, else they will not display – I think this is correct.So, logically… If permissions other than 755
are applied to selected icons in that theme they will not display in Dolphin and the resources previously used will be freed.
Therefore, if the dolphin is made of wood, it must be a duck…
The Test!
I’m in another unspecified OS currently and can’t test this, so I’ll just wait, and doodle a while till someone chimes in with their results.
_ '_
/ \
| |
| ____)
| / \/ \
/\/\ (o)(o)| I am Homer of Borg. You will be assimilated
/c \__/--. Resistance ... is ... Hmmmm, Donuts!!!
\__ -------' ___________________________________________
| / \
| | \_____)
| \_____)
| _____|
|______/\/\
/ \
Try uninstalling and replacing ffmpegthumbs
, and possibly ffmpeg
also. See if a fresh install makes any difference to the icon display.
Is there a setting somewhere to manage compositor latency?
Turn off the display, of disk and folder volumes. Maybe.
I encrypt everything, even my Steam Backup Games are encrypted.
I think it makes sense, just in case when i get maybe infected in future by a ransom crypto trojaner, it may can’t encrypt my stuff again and can’t blackmail me then.
You never know when there is a emergency, but what i learned from Sheldon Cooper, there is no need to life when all USB Ports gets destroyed
Perhaps you might get a more definitive answer on whether or not what you want is achievable (with the current version of Dolphin) over at https://discuss.kde.org
Why not use LUKS partition instead of slow veracrypt?
I use it on my external HDD with XFS.
And in at number 5, it’s The Supremes, and “Baby Love”…
Off-topic, and part of a classic segue taken from the motion picture Airplane (1980).
You do realise those files or the whole Filesystem can be re encrypted, by said Ransomware, or any other encryption tool.
Also, what @ Zesko said, if you are going to go to the unnecessary trouble of encrypting, for that reason.
I was about to suggest checking this… although it’s not clear whether the OP is talking about KDE being slow when generating thumbnails, or just displaying the default icons. It seems more likely that anything run by /usr/share/thumbnailers/*.thumbnailer
would be much slower than simply displaying icons. Maybe KDE has the equivalent of gtk-update-icon-cache
, which needs to be run? I’ve not used KDE in a long time, so I’m not sure how Plasma behaves these days.
EDIT: Maybe try:
kbuildsycoca5 --noincremental
Slow generally, is my understanding.
Ok, makes sense. I just re-read this:
In any case… messing with system-level mime types for all video files seems a heavy-handed & misguided workaround for the original problem: slowness when viewing folders of video files in Dolphin.
This (posted earlier) might still be related. The OP might think so too, considering he was in the same thread when it was originally posted:
Hmm… strange that KDE behaves slowly in that thread due to a noauto
mount, unless somehow it’s trying to auto-mount (e.g. autofs
, gvfsd
, or kio-extras
) a related NFS share or something. NFS is known to cause system hangs due to default blocking mounts, unless using the soft
mount option (usually with: bg,intr,soft
).
In any case, maybe the OP of this thread can review this KDE article about caches, and see if rebuilding the icon cache (?? command for this ?? ), and the KDE SYstem COnfiguration CAche (e.g.
kbuildsycoca5 --noincremental
for .desktop
and MIME type .xml
caches)?
This seemed to indicate network mounts:
LABEL=EXT_HD6 /srv/nfs/m/h6 ext4 noauto,users,noatime,nodev,nosuid,noexec 0 0
LABEL=EXT_HD7 /srv/nfs/m/h7 btrfs noauto,users,noatime,nodev,nosuid,noexec,compress=lzo,subvol=@ 0 0
Yeah, usually for NFSv4, the default NFS root for bind-mounts is /srv/nfs
. So, it looks like in that thread they’re setting up NFSv4 shares for use with /etc/exports
, which are backed by mounts for external drives via filesystem labels, but noauto
is set. So, the system shouldn’t auto-mount them. Not sure what KDE does in this case that makes it slow.
Unless his problem folder is symlinked to one of those drives; it would be no great wonder that his icons wouldn’t load; if that’s what was happening.
I have deactivated Thumbnails for that reason and Thumbnails also not showing in details view mode anyways.
Im actually not even sure if this icon’s are the real problem here or why my HDD is reading every file only just because i open a folder… it was a simple suggestions, that it may are connected to this icons… i just wondering why it can take this long to open it… only because its a HDD and no SSD?
Anyways, i don’t want to mess with my OS to heavily… i prefer to try things out that i can easy revert without destroying my Manjaro install.
I openend this Topic for a possible quick solution and if there is anything its still not a big issue for me and I don’t want to waste anyone’s time here.
The quickest solution, with the least amount of issues for your OS install, would be to NOT encrypt your files.
Given the reasons you gave for doing so, it is a pointless and futile exercise.
There could be many reasons why an external HDD is appearing to behave slower, including:
baloo
, GNOME’s gnome-tracker
+ tracker-miner
, or Spotlight on macOS)*.thumbnailer
s
.desktop
app launcher & file-handler caches, MIME-type caches, & other system caches
$XDG_CACHE_HOME
(default: ~/.cache
).desktop
app-launchers and their supported MIME-types for default file handlingThis topic was automatically closed 2 days after the last reply. New replies are no longer allowed.