this might not be a dolphin problem, as it also locks up the desktop, but i'm not sure what would be a better component. i've searched around for an existing bugreport, and bug #342056 seems similar - but the symptoms and the cause seem to be somewhat different here. when moving files and the source directory contains lots of files, the source dolphin window becomes unresponsive for some time. whole desktop (taskbar, systray, notifications etc) completely lock up for an even longer time. experiencing this with jpg files specifically. happens both with previews enabled and disabled. this does not happen when moving one or two files. moving 7 files locks the system up for some 4 seconds. moving 20 files locks the system up for some 13-20 seconds. larger amounts of files moved lock the system up for a much longer time. note that actual applications work perfectly fine, and it is possible to alt-tab to them. the kde panel (including systray, taskbar, menu, notification and other popups) is the only thing that locks up. the source dolphin window also locks up, but for a shorter period of time. this is tied to the amount of files in the source window and the amount of files moved. moving images into the directory with many files works much faster. Reproducible: Always Steps to Reproduce: 1. have a directory with a large amount of files - for example, 1500 2. select some of those files - for example, 100 3. move them to another directory (ctrl-x, ctrl-v in another dolphin window) Actual Results: the source dolphin window locks up for some time. taskbar, systray, all popups lock up for an even longer time. Expected Results: files are moved instantly, like they did in kde4
the cpu usage does not seem to increase much during the lockup time - plasmashell eats ~ 1.3% the part about no lockup when moving files into the directory with lots of files was wrong - actually, it does seem to lock up in a similar way (it's an operation i don't do often and apparently i messed up my tests a bit) disabling "track file transfers and other jobs" for notifications does not seem to help
I have something similar, but only Dolphin seems to be affected. Whenever I write a file to whatever filesystem (I tested my SSD, HDD and Network Share) Dolphin becomes unresponsive/freezes for several seconds. * Open a file with Kate * Change some characters * Save * Go back to dolphin * No UI update for several seconds
I'm experiencing the same bug: copying files from dolphin to dolphin (drag 'n drop or CTRL+X/V) the plasma shell becames unresponsive for some seconds. I'm using a quite recent PC (CPU Intel i7 4770K, 16gb RAM). Copying about 20 files will stops the shell for at least 10 seconds. Dolphin 16.08.1, KDE 5.26.0, Qt 5.7.0
Similar/duplicate 369568
*** Bug 369568 has been marked as a duplicate of this bug. ***
Well I "fixed" it by creating a new user/home directory. I tried deleting some of the config files in my old home but couldn't figure out which one caused the trouble.
I can confirm this bug both on kde neon and debian buster (plasma 5.10) as new user with the default configuration. Moving many files (in my case 177 files with a total 340 MiB) causes the plasma shell to hang for quite sime time. This is especially grave when overwriting some or all of the destination files. The cpu load is low and all applications except the panel etc. remain responsive. This "hanging" continues for an unknown duration (at least several minutes), even after the moving/overwring of files is finished. However closing all dolphin instances (after the process is finished) immideatedly makes the whole system responsive again.
I cannot remember that I had this issue in the past (i.e. at the time this ticket was reported), but since recently, I also experience this. Moving a single folder with many items works fine, but selecting all items in the folder, and moving them in one go causes the described lockup for minutes after moving.
duplicate? https://bugs.kde.org/show_bug.cgi?id=378935
*** Bug 378935 has been marked as a duplicate of this bug. ***
Git commit e1fe26f1fc78082fdb215cb818177541d4607d9c by Jaime Torres. Committed on 19/02/2018 at 20:09. Pushed by jtamate into branch 'master'. Reduce plasmashell frozen time to almost nothing Summary: Related: bug 342056 Even the icon with the number of tasks pending moves from time to time. To reduce the frozen time, a similar patch must be applied also to frameworks/kwindowsystem src/platforms/xcb/kxmessages.cpp frameworks/plasma-framework src/plasma/private/effectwatcher.cpp According to the documentation (and a look to the source code) http://doc.qt.io/qt-5/qabstractnativeeventfilter.html The type of event eventType is specific to the platform plugin chosen at run-time, and can be used to cast message to the right type. On X11, eventType is set to "xcb_generic_event_t", and the message can be casted to a xcb_generic_event_t pointer. The other eventType are "windows_generic_MSG" and "mac_generic_NSEvent". No other eventType starts with an 'x'. Test Plan: Cut & paste 2000 small files. Before, a freeze (plasmashell not responding) of minutes After, a freeze of seconds Reviewers: #frameworks, #plasma, davidedmundson Reviewed By: #plasma, davidedmundson Subscribers: broulik, davidedmundson, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D10627 M +1 -1 shell/screenpool.cpp https://commits.kde.org/plasma-workspace/e1fe26f1fc78082fdb215cb818177541d4607d9c
*** Bug 393748 has been marked as a duplicate of this bug. ***
I'm not convinced this problem has been fully fixed .. yes, git commit e1fe26f1fc78082fdb215cb818177541d4607d9c by Jaime Torresit's has reduced the plasma hang time but 9 seconds to move 1000 1Mb files on the same partition on a HDD that takes the mv command less than a 10th of a second is still not right. Here's my comments from https://bugs.kde.org/show_bug.cgi?id=393748 "I've tested the developer edition 20180508-1053 today and although you have improved things ie plasma panel only hangs for 4 seconds for a 120 file move (9 seconds for a 1000 file move. You've not fixed the plasma panel/desktop freeze Looking at Dolphin stderr it outputs this message "QXcbClipboard: SelectRequest too old" 11,900 times during the period plasma panel has hung. So sorry guys it's not been fixed. As before this problem is 100% reproducible using the procedure I used above. During the panel freeze the CPU is idle & all disc I/O completed within a second. I know I'm not familiar with the code but I would have thought the error "QXcbClipboard: SelectRequest too old" was a good place to start. Find the cause of that and you might just find why plasma freezes ?. I've reopened this bug and I'm assuming I'm looking at the latest code although I did download dev stable rather than dev unstable."
I should just clarify plasma freezes for 9 seconds, the file move operation completes in less than a second. I may have given the impression the file move took 9 seconds for 1000 files.
*** Bug 375781 has been marked as a duplicate of this bug. ***
*** Bug 386781 has been marked as a duplicate of this bug. ***
*** Bug 383660 has been marked as a duplicate of this bug. ***
Probably relates to https://bugs.kde.org/show_bug.cgi?id=390748 except it concerns deletion operation.
I can confirm this on Arch Linux. Moving as few as 10 small files using Dolphin can cause the desktop to freeze for 10 seconds or so. plasma-desktop package is 5.13.5-1 and dolphin is 18.08.1-2
I've just opened this bug which might be related : https://bugs.kde.org/show_bug.cgi?id=400025
*** Bug 400025 has been marked as a duplicate of this bug. ***
This problem persists. Operating System: Arch Linux KDE Plasma Version: 5.15.1 KDE Frameworks Version: 5.55.0 Qt Version: 5.12.1 Kernel Version: 4.20.11-arch2-1-ARCH OS Type: 64-bit Processors: 2 × Intel® Celeron® CPU G1820 @ 2.70GHz Memory: 7,7 GiB of RAM
*** Bug 404026 has been marked as a duplicate of this bug. ***
*** Bug 404751 has been marked as a duplicate of this bug. ***
This problem just happened on my system while Dolphin moved 358 small jpg files from a ntfs partition to my Home . Operating System: Arch Linux KDE Plasma Version: 5.16.90 KDE Frameworks Version: 5.62.0 Qt Version: 5.14.0 beta1
Still happening. Operating System: Arch Linux KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.68.0 Qt Version: 5.14.2
I suspect that the issue is mostly X server specific. Could someone confirm ?
Created attachment 127290 [details] "zombie" notifications At least on Neon unstable I can only reproduce this problem on X11. Sometimes I also get 'zombie" notifications after files moving to be completed. And when I close Dolphin while these "zombie" notifications are active, Plasma shows "job failed" notifications as we can see in the attached screenshot. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.18.80 KDE Frameworks Version: 5.69.0 Qt Version: 5.14.1
Created attachment 127291 [details] "job failed" notification
This problem persists. Operating System: Arch Linux KDE Plasma Version: 5.20.2 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.1
*** Bug 368480 has been marked as a duplicate of this bug. ***
Same here, still happening on manjaro with plasma 5.20.3 I confirm it happens only on X, unfortunately the wayland "ecosystem" is not there yet so I think a fix should be investigated for this issue on a fundamental/core functionality like this (moving a bunch of files!). Thanks for your hard and appreciated work!
Hi, Below a good way to reproduce the issue: 1) Create folder A 2) Put dozen/hundreds of files in folder A 3) Create folder B at the same level of folder A 4) Move the files from folder A to folder B 5) Immediately delete folder A Plasma shell will freeze for a minute or more and then recover with a ghost notification Thank you
I still have this problem on my laptop with a SATA SSD and formatted as ext4. System updates or just about any significant file operation will lock the system up. But I managed to completely solve the problem on my PC (where I had the same issues) when I migrated to a NVMe SSD formatted as f2fs. I don't think the NVMe part should have been that significant because SATA is still plenty fast and doesn't lock up in other DEs or OS'. Ext4 is also fine in other DEs from recollection, but perhaps something in KDE just doesn't work well with it but works OK with f2fs. IIRC changing the schedulers doesn't help. If someone wants me to do more rigorous testing just give me steps and I'll give it a try.
Confirmed with one large file, a hang occurs between drag and drop and the appearance of the move or copy selection menu, with graphical artifacts (see screenshot). At the same time, you can hear how the hard disk starts working at this moment, after some time the "move or copy" selection menu appears, and after that the file is instantly copied. Operating System: openSUSE Tumbleweed 20220824 (latest) KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.19.2-1-default (64-bit) Graphics Platform: X11
Created attachment 151594 [details] Hang with graphical artifacts
Created attachment 151631 [details] Video demonstration of the problem. I have exactly the same problem. When copying a file, the shell freezes (but not Dolphin), but if you copy an entire folder, plasma does not hang. I tried copying a file or folder through the console with the cp and rsync command. When copying through the console, the shell did not hang. The problem manifests itself on both X11 and Wayland. System: Arch Linux KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Linux Kernel version: 5.15.62-1-lts The entire system has been updated to the latest version.
Marking this bug confirmed, at it affects multiple users.
(In reply to DarkVessel from comment #37) > I have exactly the same problem. When copying a file, the shell freezes (but > not Dolphin), but if you copy an entire folder, plasma does not hang. LOL! Same issue here too. At first I thought it had to do with the file being *large*, yet if it involves a *FOLDER* (whether containing a single or multiple large files, doesn't matter) then it smoothly glides through the entire copy operation! I thought I was going crazy until I came across this bug report. The trick of copying a FOLDER (instead of a large FILE) magically works. Not sure why... . . . Operating System: Manjaro Linux KDE Plasma Version: 5.24.6 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Kernel Version: 5.19.1-3-MANJARO (64-bit) Graphics Platform: X11 Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics
Ohhhhhhh, just discovered something interesting while testing your method, @DarkVessel. What happens if you NAVIGATE to the folder *while* the copy operation is in progress? While the folder copy operation is running, and the system is fine, I can re-create the "freeze" by entering the folder before it finishes. It is not until the copy operation is finished will I regain control of the desktop. So this might have something to do with Dolphin/KDE/KIO/Plasma/whatever updating/refreshing the view of the current folder that is the destination of a large copy operation?
(In reply to flan_suse from comment #40) > Ohhhhhhh, just discovered something interesting while testing your method, > @DarkVessel. > > What happens if you NAVIGATE to the folder *while* the copy operation is in > progress? > > While the folder copy operation is running, and the system is fine, I can > re-create the "freeze" by entering the folder before it finishes. It is not > until the copy operation is finished will I regain control of the desktop. > > So this might have something to do with Dolphin/KDE/KIO/Plasma/whatever > updating/refreshing the view of the current folder that is the destination > of a large copy operation? I'm not seeing this behaviour in a later version of KDE I'm running (KDE Neon). Dragging a file 300+MB to the desktop. How big are the files you are dragging to the desktop? Operating System: KDE neon 5.26 KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 Kernel Version: 5.15.0-60-generic (64-bit) Graphics Platform: X11 Processors: 20 × 12th Gen Intel® Core™ i7-12700H Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® Graphics
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
I can't confirm when dragging a directory with lots of files (740 pictures) from dolphin to desktop, BUT can confirm when dragging a single big file (1.7 GB) from dolphin to desktop. Plasmashell freezes for about 10 seconds, then context menu appears. File is on HDD, system & desktop on NVME SSD. Just like in the attached video by Zhora Zmeikin https://bugs.kde.org/attachment.cgi?id=151631 dolphin/lunar,now 4:22.12.2-0ubuntu1 amd64 Operating System: Kubuntu 23.04 KDE Plasma Version: 5.27.0 (there are some 5.26.5 and 5.26.90 packages) KDE Frameworks Version: 5.103.0 (there are some 5.102 and even 5.101 packages, Kubuntu Lunar is a mess) Qt Version: 5.15.8 Kernel Version: 5.19.0-21-generic (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 31.3 ГиБ of RAM Graphics Processor: AMD Radeon RX 590 Series Manufacturer: ASUS
Copying an 8 Gigabyte file across any devices that do NOT hold the system does not trigger the freeze for me. However, copying it to the physical device THAT HOLDS the system installation, does cause panels and dolphin to become sluggish; if I continue trying to do stuff, like opening other dolphin views or emptying the trash, it would eventually become non responsive unless the transfer is cancelled or completed. This does not happen at all if cp in a terminal is used for the operation. The problem may be less noticeable in faster devices, so if you are not being able to reproduce it, try with files that are way larger than the speed of the device where your system is installed. Operating System: KDE neon 5.27 KDE Plasma Version: 5.27.1 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 5.19.0-32-generic (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4670 CPU @ 3.40GHz Memory: 31.3 GiB of RAM File system: BTRFS System's storage device: SATA 3 SSD
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1255
Git commit b9e5af7babc9d68af70e303528ed027e3d61d501 by Harald Sitter. Committed on 21/04/2023 at 11:54. Pushed by sitter into branch 'master'. file: make sure to cancel reading if the worker was aborted otherwise we end up stuck waiting for the thread to terminate while the thread is busy needlessly reading the file, when all we wanted was mimetype data. M +3 -0 src/kioworkers/file/file.cpp https://invent.kde.org/frameworks/kio/commit/b9e5af7babc9d68af70e303528ed027e3d61d501
Git commit 804d58c260b63b182ebcdd1c445d9e6fecea27c9 by Harald Sitter. Committed on 21/04/2023 at 12:12. Pushed by sitter into branch 'kf5'. file: make sure to cancel reading if the worker was aborted otherwise we end up stuck waiting for the thread to terminate while the thread is busy needlessly reading the file, when all we wanted was mimetype data. (cherry picked from commit b9e5af7babc9d68af70e303528ed027e3d61d501) M +4 -0 src/ioslaves/file/file.cpp https://invent.kde.org/frameworks/kio/commit/804d58c260b63b182ebcdd1c445d9e6fecea27c9
*** Bug 444631 has been marked as a duplicate of this bug. ***