IridiumIO
Cancelling isn't working
I was trying to compress a ~50gb game on a HDD that had more than 100 free but it still ate it up to the last few MBs, I tried the cancel button but it stays on cancelling.. forever and it just ignores it and keeps on trying to compress. I think if possible should only be one file in the queue instead of trying to queue the whole operation.
I've added an option to limit compression to one thread which might help this issue, but I feel like there's a deeper problem causing it to eat up your disk space, similar to #325 .
In other cases, the reason cancelling takes so long is because the program must finish compressing the current file before it can close. If the program is partway through compressing a single 50GB file, then that compression must finish before it cancels.
Cancelling isn't working for me either. I pressed cancel and waited for it to finish the current file, and instead of stopping, it just moved on to the next file. And it didn't stop after that file either, it just keeps going.
Can confirm. Cancelling isn't working per se. It does not stop (and in fact - never did) after the currently compressed file (as if you haven't pressed anything), and just goes on, from one file to the next one, on and on - until the whole folder is processed. The only way to "stop" it - is to kill the process (through stock task manager, or via any other third-party ones).
It seems that it's similar to the "Cancel" button when you shut down or restart Win10 - it does absolutely nothing as well, no matter whether you clicked it right after it appeared or not (hence, plenty of time to actually, you know ... cancel). =)
Can you guys confirm that it still doesn't work if you limit compression to a single thread? If you have a high core count CPU (e.g 16 cores) there's a good chance the scheduler has spun up 16 separate compressions in parallel that all have to complete before cancellation can occur.
I really can't replicate this issue on my end
Can you guys confirm
Sure thing (28 CPU threads here). Tested both on an SSD, HDD (with its option ticked, unless stated otherwise), and a RAM disk (just to be sure). Both v3.8 and v4.0 beta 4 (they behaved the same, unless stated otherwise). Algo: Xpress16K.
Made three test folders with files from random games. First one with a single 5GB file (to eliminate the multithread option per se), second one with five 1GB files (to get a bit of multithreading, yet not saturate all the threads), and the third one with fifty six 500MB files (twice the amount of threads, to 100% test the "all threads finished" theory). Made sure that these files are compressable (and not skippable, ofc) to some degree - so that the algo has enough numbers to crunch.
First folder wasn't stopping until the file is finished compressing (which is obvious, but, again - to be sure) on both 0 (auto) threads and 1 forced thread. Results: 1/1 files compressed when cancelled at 0 (auto) threads, 1/1 files compressed when cancelled at 1 thread. Both are 1/1 for HDD.
Second folder, on 0 (auto) threads - hasn't stopped compressing, even though I clicked the "Cancel" button right after it started compressing. But when I forced it to 1 thread - it did stop after compressing one random file (not the first one by the file name - but just random, which is weird by its own, but that's a question for an another topic). Results: 5/5 files compressed when cancelled at 0 (auto) threads, 1/5 files compressed when cancelled at 1 thread. Both are 1/5 for HDD.
Third folder: same as the second folder, but, ofc - now it's limited by the thread count. Results: 28/56 (16/56 on v3.8 for some reason) files compressed when cancelled at 0 (auto) threads, 1/56 files compressed when cancelled at 1 thread. Both are 1/56 for HDD.
But! If the free space on a storage drive is low enough (noticed that with the RAM disk, as I created one couple about twice the size of total size of the files tested), yet still enough for the "beefiest" file in the folder, ofc - the cancelling results at 3-5 files compressed instead of the "full thread" amount. I don't know how it's related, but I'm here merely just to add the extra info.
So, yes, forcing it to 1 thread does stop the compression after 1 (or more, if the storage is fast enough) random file.
Gonna add on here and say that I tried canceling while uncompressing and the entire program just froze. After like a solid 5 minutes, it crashed. When I reopened it, ALL of my watched folders where now gone?! Thankfully adding back the folders to the list is easy, but that it even happened is bizarre. Coincidentally, this also happened just when beta 4 came out (I was using beta 3).
Gonna add on here and say that I tried canceling while uncompressing and the entire program just froze. After like a solid 5 minutes, it crashed. When I reopened it, ALL of my watched folders where now gone?! Thankfully adding back the folders to the list is easy, but that it even happened is bizarre. Coincidentally, this also happened just when beta 4 came out (I was using beta 3).
Can you check the Windows Event Viewer to see what the crash report says, and share it here?