[plasmashell] [Bug 364526] Plasma crashes on monitor energy saving mode (FrameSvg related)
https://bugs.kde.org/show_bug.cgi?id=364526 --- Comment #5 from Amichai Rothman --- This issue stopped happening a while back, after I deleted one of the config files (I don't remember exactly which, probably one of the plasma*rc). It's unfortunate that plasma crashes due to a config file, which itself was modified only by the software, never by me manually - so there may be additionally another bug of how the config file got to that state, if it is indeed an invalid state. Unfortunately I don't have the old config file, so all you have to work with is the stack trace I originally provided. It's up to you whether you want to pursue this (since there was definitely a bug somewhere) or close the issue now that a workaround was found. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373181] New: Panel disappears (moves to invalid screen)
https://bugs.kde.org/show_bug.cgi?id=373181 Bug ID: 373181 Summary: Panel disappears (moves to invalid screen) Product: plasmashell Version: 5.7.5 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: amich...@amichais.net Target Milestone: 1.0 I have a 2 monitor setup (Intel IGPU), running Kubuntu 16.10. Several times a day (I think it's when the monitors go in or out of power savings mode), the panel disappears; sometimes it re-appears in the same place, sometimes it re-appears on the other monitor (so over the course of a day it might move back and forth between the two monitors), and sometimes it doesn't re-appear at all. I figured out that when it disappears completely, I can edit ~/.config/plasma-org.kde.plasma.desktop-appletsrc, search for all instances of 'lastScreen=X' and replace X with 0 or 1, and restart plasmashell. Interestingly, and this is probably the source of the bug, when I look at all the values of X in the file, it's full of invalid screen numbers - just now I saw values range between 0 and 8. For some reason it seems to be incrementing the screen number at some point, even though it gets to invalid values, rather than limiting them to only valid screen numbers. And to clarify, there is no reason for it to be updating this value at all as far as I know... I'm not actually moving the panel or other widgets around between screens. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 278381] Ark cannot open iso cd image
https://bugs.kde.org/show_bug.cgi?id=278381 --- Comment #13 from Amichai Rothman --- Still an issue with Ark 19.12.3 on Kubuntu 20.04.2. Ark shows a notification saying "The archive is empty or Ark could not open its content". A mount -o loop shows the content with no issue. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 278381] Ark cannot open iso cd image
https://bugs.kde.org/show_bug.cgi?id=278381 --- Comment #15 from Amichai Rothman --- First I tried: $bsdtar -t bad.iso bsdtar: Error opening archive: Failed to open '/dev/st0' Then googled a bit and tried: $bsdtar -t -f bad.iso and the command completed with no output (no error and no listing). If you're in a position to fix this, u can contact me privately and I'll send you the iso somehow... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 354541] panel flickers a lot
https://bugs.kde.org/show_bug.cgi?id=354541 --- Comment #8 from Amichai Rothman --- After having these annoying flickering bugs for a long while, they went away and all graphics was smooth for a while. More recently in the past few months I started getting other sorts of flickering in the display again, although they seem related to the full display and not only to the panel. Specifically, I have not seen the issue during copying large files nor that only one side of the panel flickers. If I'd have to guess, I'd say the current issues I'm having are unrelated to this report, but who knows :-) -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 355153] 31G virtual memory usage
https://bugs.kde.org/show_bug.cgi?id=355153 --- Comment #5 from Amichai Rothman --- I haven't noticed this issue happening (or remembered it exists :-) ) in quite a while... we can assume it's been fixed. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373181] Panel disappears (moves to invalid screen)
https://bugs.kde.org/show_bug.cgi?id=373181 --- Comment #3 from Amichai Rothman --- When 5.8.4 or later is backported to Kubuntu 16.10, I'll install and test it. They used to backport every point release, but nowadays it seems there are large gaps in KDE backports. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373181] Panel disappears (moves to invalid screen)
https://bugs.kde.org/show_bug.cgi?id=373181 --- Comment #4 from Amichai Rothman --- I think it is indeed solved in 5.8.4. Although the panel does sometimes move from one monitor to the other after returning from monitor power savings mode, it no longer disappears completely nor moves to an invalid monitor number. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 364526] Plasma crashes on monitor energy saving mode (FrameSvg related)
https://bugs.kde.org/show_bug.cgi?id=364526 --- Comment #3 from Amichai Rothman --- The theme is Breeze. I think I did select to load debug symbols from the crash dialog - how should I install whatever is missing? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 364526] New: Plasma crashes on monitor energy saving mode
https://bugs.kde.org/show_bug.cgi?id=364526 Bug ID: 364526 Summary: Plasma crashes on monitor energy saving mode Product: plasmashell Version: 5.5.5 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: amich...@amichais.net CC: bhus...@gmail.com, plasma-b...@kde.org Application: plasmashell (5.5.5) Qt Version: 5.5.1 Operating System: Linux 4.4.0-24-generic x86_64 Distribution: Ubuntu 16.04 LTS -- Information about the crash: - Unusual behavior I noticed: Whenever the monitors should go into energy saving mode (after not using the pc for the specified amount of time), the screens do go blank for a few seconds, but then turn right back on. This is accompanied by a plasma crash dialog. If I leave the pc for several hours, I come back to a whole pile of such crash dialogs on top of each other. On Kubuntu 16.04, kernel 4.4.0-24-generic, Intel Graphics 4600 (Haswell), plasma-desktop 4:5.5.5-0ubuntu1. The crash can be reproduced every time. -- Backtrace: Application: Plasma (plasmashell), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f39697238c0 (LWP 29723))] Thread 8 (Thread 0x7f3954913700 (LWP 29726)): #0 0x7f3963e3be8d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7f3967f00c62 in () at /usr/lib/x86_64-linux-gnu/libxcb.so.1 #2 0x7f3967f028d7 in xcb_wait_for_event () at /usr/lib/x86_64-linux-gnu/libxcb.so.1 #3 0x7f3956a61629 in () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #4 0x7f396453184e in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f396361e6fa in start_thread (arg=0x7f3954913700) at pthread_create.c:333 #6 0x7f3963e47b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 7 (Thread 0x7f394dff2700 (LWP 29728)): #0 0x7f3963e3be8d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7f3960bd231c in g_main_context_iterate (priority=2147483647, n_fds=1, fds=0x7f3948003070, timeout=, context=0x7f3948000990) at /build/glib2.0-t9oPgV/glib2.0-2.48.0/./glib/gmain.c:4135 #2 0x7f3960bd231c in g_main_context_iterate (context=context@entry=0x7f3948000990, block=block@entry=1, dispatch=dispatch@entry=1, self=) at /build/glib2.0-t9oPgV/glib2.0-2.48.0/./glib/gmain.c:3835 #3 0x7f3960bd242c in g_main_context_iteration (context=0x7f3948000990, may_block=1) at /build/glib2.0-t9oPgV/glib2.0-2.48.0/./glib/gmain.c:3901 #4 0x7f3964768a9b in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f396470fdea in QEventLoop::exec(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f396452c8a4 in QThread::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7f3966dd43c5 in () at /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #8 0x7f396453184e in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x7f396361e6fa in start_thread (arg=0x7f394dff2700) at pthread_create.c:333 #10 0x7f3963e47b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 6 (Thread 0x7f3942ac3700 (LWP 29729)): #0 0x7f3963e3be8d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7f3960bd231c in g_main_context_iterate (priority=2147483647, n_fds=1, fds=0x7f393c002e70, timeout=, context=0x7f393c000990) at /build/glib2.0-t9oPgV/glib2.0-2.48.0/./glib/gmain.c:4135 #2 0x7f3960bd231c in g_main_context_iterate (context=context@entry=0x7f393c000990, block=block@entry=1, dispatch=dispatch@entry=1, self=) at /build/glib2.0-t9oPgV/glib2.0-2.48.0/./glib/gmain.c:3835 #3 0x7f3960bd242c in g_main_context_iteration (context=0x7f393c000990, may_block=1) at /build/glib2.0-t9oPgV/glib2.0-2.48.0/./glib/gmain.c:3901 #4 0x7f3964768a9b in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f396470fdea in QEventLoop::exec(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f396452c8a4 in QThread::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7f3966dd43c5 in () at /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #8 0x7f396453184e in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x7f396361e6fa in start_thread (arg=0x7f3942ac3700) at pthread_create.c:333 #10 0x7f3963e47b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 5 (Thread 0x7f3940c09700 (LWP 29730)): #0 0x7f3963e3be8d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7f3960bd231c in g_main_context_iterate (priority=2147483647, n_fds=1, fds=0x7f3934003070, timeout=, context=0x7f3934000990) at /build/glib2.0-t9oPgV/glib2.0-2.48.0/./glib/gmain.c:4135 #2 0x7f3960bd231c in g_main_context_iterate (context=
[plasmashell] [Bug 364769] New: Plasma crash after monitor suspend/resume
https://bugs.kde.org/show_bug.cgi?id=364769 Bug ID: 364769 Summary: Plasma crash after monitor suspend/resume Product: plasmashell Version: 5.5.5 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: amich...@amichais.net CC: bhus...@gmail.com, plasma-b...@kde.org Application: plasmashell (5.5.5) Qt Version: 5.5.1 Operating System: Linux 4.4.0-24-generic x86_64 Distribution: Ubuntu 16.04 LTS -- Information about the crash: - Unusual behavior I noticed: When leaving the computer for a while and returning, instead of the monitors being suspended, they are on and this plasma crash dialog appears, often several of them. The crash can be reproduced every time. -- Backtrace: Application: Plasma (plasmashell), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7fb4121078c0 (LWP 4707))] Thread 8 (Thread 0x7fb355695700 (LWP 4727)): #0 0x7fb40c81fe8d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7fb4095b639c in g_main_context_iterate (priority=2147483647, n_fds=1, fds=0x7fb35000e8f0, timeout=, context=0x7fb35000f9e0) at /build/glib2.0-7IO_Yw/glib2.0-2.48.1/./glib/gmain.c:4135 #2 0x7fb4095b639c in g_main_context_iterate (context=context@entry=0x7fb35000f9e0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at /build/glib2.0-7IO_Yw/glib2.0-2.48.1/./glib/gmain.c:3835 #3 0x7fb4095b64ac in g_main_context_iteration (context=0x7fb35000f9e0, may_block=1) at /build/glib2.0-7IO_Yw/glib2.0-2.48.1/./glib/gmain.c:3901 #4 0x7fb40d14ca9b in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7fb40d0f3dea in QEventLoop::exec(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7fb40cf108a4 in QThread::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7fb3478497d7 in KCupsConnection::run() () at /usr/lib/x86_64-linux-gnu/libkcupslib.so #8 0x7fb40cf1584e in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x7fb40c0026fa in start_thread (arg=0x7fb355695700) at pthread_create.c:333 #10 0x7fb40c82bb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 7 (Thread 0x7fb3e128c700 (LWP 4722)): #0 0x7fb4095faac9 in g_mutex_lock (mutex=mutex@entry=0x7fb358015340) at /build/glib2.0-7IO_Yw/glib2.0-2.48.1/./glib/gthread-posix.c:1335 #1 0x7fb4095b5f26 in g_main_context_dispatch (context=context@entry=0x7fb358015340) at /build/glib2.0-7IO_Yw/glib2.0-2.48.1/./glib/gmain.c:3765 #2 0x7fb4095b6400 in g_main_context_iterate (context=context@entry=0x7fb358015340, block=block@entry=1, dispatch=dispatch@entry=1, self=) at /build/glib2.0-7IO_Yw/glib2.0-2.48.1/./glib/gmain.c:3840 #3 0x7fb4095b64ac in g_main_context_iteration (context=0x7fb358015340, may_block=1) at /build/glib2.0-7IO_Yw/glib2.0-2.48.1/./glib/gmain.c:3901 #4 0x7fb40d14ca9b in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7fb40d0f3dea in QEventLoop::exec(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7fb40cf108a4 in QThread::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7fb41013eed6 in () at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5 #8 0x7fb40cf1584e in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x7fb40c0026fa in start_thread (arg=0x7fb3e128c700) at pthread_create.c:333 #10 0x7fb40c82bb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 6 (Thread 0x7fb3e3bd8700 (LWP 4715)): #0 0x7fb40c0083a0 in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7fb411b5dbd4 in () at /usr/lib/x86_64-linux-gnu/libQt5Script.so.5 #2 0x7fb411b5dc19 in () at /usr/lib/x86_64-linux-gnu/libQt5Script.so.5 #3 0x7fb40c0026fa in start_thread (arg=0x7fb3e3bd8700) at pthread_create.c:333 #4 0x7fb40c82bb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 5 (Thread 0x7fb3e95a4700 (LWP 4714)): #0 0x7fb40c81fe8d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7fb4095b639c in g_main_context_iterate (priority=2147483647, n_fds=1, fds=0x7fb3dc003070, timeout=, context=0x7fb3dc000990) at /build/glib2.0-7IO_Yw/glib2.0-2.48.1/./glib/gmain.c:4135 #2 0x7fb4095b639c in g_main_context_iterate (context=context@entry=0x7fb3dc000990, block=block@entry=1, dispatch=dispatch@entry=1, self=) at /build/glib2.0-7IO_Yw/glib2.0-2.48.1/./glib/gmain.c:3835 #3 0x7fb4095b64ac in g_main_context_iteration (context=0x7fb3dc000990, may_block=1) at /build/glib2.0-7IO_Yw/glib2.0-2.48.1/./glib/gmain.c:3901 #4 0x7fb40d14ca9b in QEventDispatcherGlib::processEvents(Q
[kwin] [Bug 363093] New: Tearing prevention (vsync) settings lost when monitor turns on/off
https://bugs.kde.org/show_bug.cgi?id=363093
Bug ID: 363093
Summary: Tearing prevention (vsync) settings lost when monitor
turns on/off
Product: kwin
Version: 5.5.5
Platform: Kubuntu Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: multihead
Assignee: kwin-bugs-n...@kde.org
Reporter: amich...@amichais.net
Since the upgrade to Kubuntu 16.04, every time I turn on my TV (third monitor)
there is lots of tearing when viewing videos. This is with an Intel i7 Haswell
integrated GPU (no dedicated graphics card). The workaround is to go to System
Settings -> Compositor and re-apply the Tearing prevention ("vsync") setting
manually every time - it is set to "Full screen repaints", which is the correct
option, but in order to re-apply it I need to select a different option and
then "Full screen repaints" again and then click Apply, and everything is back
to normal (no tearing) as long as the TV stays on. I have to do this every
single time I turn on the TV for video to be watchable. This was not an issue
in previous versions, where the setting always remained in effect and I never
had to touch it regardless of turning anything on or off.
Reproducible: Always
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 363093] Tearing prevention (vsync) settings lost when monitor turns on/off
https://bugs.kde.org/show_bug.cgi?id=363093 --- Comment #2 from Amichai Rothman --- Created attachment 98983 --> https://bugs.kde.org/attachment.cgi?id=98983&action=edit xrandr -q output (without TV) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 363093] Tearing prevention (vsync) settings lost when monitor turns on/off
https://bugs.kde.org/show_bug.cgi?id=363093 --- Comment #3 from Amichai Rothman --- Created attachment 98984 --> https://bugs.kde.org/attachment.cgi?id=98984&action=edit xrandr -q output (with TV) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 363093] Tearing prevention (vsync) settings lost when monitor turns on/off
https://bugs.kde.org/show_bug.cgi?id=363093 --- Comment #4 from Amichai Rothman --- Attached xrandr outputs as requested. How do I suspend/resume the compositor? under compositor settings I only see a "Enable compositor on startup" option. Everything you say about sync may be true. As a user all I know is that it worked and I never had to think about it, and now it's broken and requires annoying configuration changes before every use. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 363093] Tearing prevention (vsync) settings lost when monitor turns on/off
https://bugs.kde.org/show_bug.cgi?id=363093 --- Comment #6 from Amichai Rothman --- The TV (HDMI1) should be synced. It appears that suspending and resuming the compositor actually fixes the problem (temporarily). Here's my full experiment (all tests are with VLC playing full screen video on one of the monitors): I started off with all 3 monitors on, and applied the vsync from the settings, so that the video runs on the TV without tearing. Then I turn off the TV and move the video to the first screen and second screen - both of them have tearing. Then I turn on the TV again - now there's tearing on all 3 screens. I then press SHIFT+ALT+F12 to suspend the compositor, and the tearing on the TV is gone - everything is ok again. If I press SHIFT+ALT+F12 again to resume the compositor, everything stays the same - there video is still ok with no tearing. That brings me back to the initial state of this test. At least now I have a shorter workaround - instead of fiddling with settings, I can just press SHIFT+ALT+F12 twice, so it's a little more bearable. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 363093] Tearing prevention (vsync) settings lost when monitor turns on/off
https://bugs.kde.org/show_bug.cgi?id=363093 --- Comment #8 from Amichai Rothman --- I can see in both kscreen and xrandr that DP1 is primary. If I change it to HDMI1 then the KDE panel moves to the TV (which is NOT what I want), but it doesn't affect the tearing. As I stated above, if I restart the compositor it fixes the problem temporarily anyway, so I'm not sure what to look for with regards to the primary display change. btw, thanks a lot for the quick responses and troubleshooting suggestions! -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 348591] System Load Viewer widget in panel can't show individual cores/cpus
https://bugs.kde.org/show_bug.cgi?id=348591 --- Comment #16 from Amichai Rothman --- I can confirm - this functionality has returned and is working well. You may close the issue. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 323072] File extensions not saved and unconfigurable
https://bugs.kde.org/show_bug.cgi?id=323072 --- Comment #4 from Amichai Rothman --- I can confirm that Ark now opens the files regardless of file extension. Thanks for the fix! -- You are receiving this mail because: You are watching all bug changes.
[ktorrent] [Bug 357160] KTorrent GUI freezes randlomly and stops torrent downloads
https://bugs.kde.org/show_bug.cgi?id=357160 Amichai Rothman changed: What|Removed |Added CC||amich...@amichais.net --- Comment #3 from Amichai Rothman --- Duplicate of bug #354633 ? -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 348591] System Load Viewer widget in panel can't show individual cores/cpus
https://bugs.kde.org/show_bug.cgi?id=348591 --- Comment #11 from Amichai Rothman --- This should not be filed under wishlist but as a pretty big regression bug, since this functionality exists in previous versions but is now broken. Just mentioning this in case it helps in prioritization, so it doesn't get pushed down the todo list :-) -- You are receiving this mail because: You are watching all bug changes.
[ktorrent] [Bug 354633] [ntfs] ktorrent freezes very often
https://bugs.kde.org/show_bug.cgi?id=354633 --- Comment #14 from Amichai Rothman --- Just wanted to give more specific info that I now have: It happens on two different HDD NTFS drives, so it's less likely to be related to failed disk, and does not happen on btrfs HDD or ext4 SSD. It appears to happen more (not 100% sure) with faster download speeds (MB/s as opposed to KB/s). Also, both drives are relatively full - iirc at some point NTFS starts writing data blocks to the MFT when it gets crowded, I don't know at what threshold but maybe it's somehow related? Can others check how full their problematic drives are to potentially reinforce or rule out this lead? -- You are receiving this mail because: You are watching all bug changes.
[ktorrent] [Bug 354633] [ntfs] ktorrent freezes very often
https://bugs.kde.org/show_bug.cgi?id=354633 --- Comment #16 from Amichai Rothman --- I certainly agree - separating business logic from UI threads is the proper design in any case, and should solve the responsiveness problem - but not necessarily the root cause of the long IO pauses themselves. According to https://support.microsoft.com/en-us/kb/174619, 12.5% of disk space is allocated to the MFT by default, and is used to store data only if the rest of the free space is exhausted. For a 131G disk that's about 16G, so it looks like your case is consistent with the theory so far. -- You are receiving this mail because: You are watching all bug changes.
