Freeze while deleting torrent+data

[Honeyfrog]

This bug is back in 1.8.1, and extremely noticeable on older, slower machines; delays can be in excess of half a minute to delete a torrent and data (torrent with one public tracker which downloaded a fraction of one piece before I stopped. No pre-allocation).

[ggp83]

I have the same problem!

Though I've used uTorrent for years and never had this problem. And I don't remember exactly when this problem started. Either it was after the 1.8.2 update, or it started after I got a new computer which was pretty recently.

What happens is that uTorrent freezes for up to 20-30 seconds, and I think I can hear my harddrive "searching" or something, I'm not sure though, because it's a very low sound.

[Ultima]

Indeed, several people have reported experiencing this issue with current versions. Is it easily reproducible?

[Ultima]

For people experiencing this problem...

- What is the default remove action shown in the Remove toolbar button's context menu?

- Do you have "Move to trash if possible" enabled?

- Exactly how are you removing the torrent? (where in the UI, or what keyboard shortcut if applicable)

[ggp83]

I right-click and select "Remove And - Delete .torrent and data".

And gui.delete_to_trash is set to true. and gui.default_del_action is set to 0. which both are default I guess, since I haven't changed them.

Edit (29/Mar/09):

I have tried deleting with gui.delete_to_tash set to false, and it seems to work okay. Haven't noticed any freezes at all. So the problem seems to be connected to the trashcan somehow, at least for me.

[SmartWater]

I have had this problem for over 6 months and it is quite horrible. I have had it on Vista 32-bit core2duo as well as Vista 64-bit i7. When I select remove and delete data, utorrent will quickly take control of 100% of my cpu and will begin deleting the data ever so slowly. Deleting multiple torrents with data results in utorrent being unresponsive for many hours to infinity.

To answer Ultima's questions...

Yes, it is very easily reproducible. I've never not gotten it really. Everything in my utorrent is default as downloaded really, the only thing I change is ports and number of connections

-I don't know what you mean by this, but when I scroll over the Red X in the toolbar, it says remove.

-I have no idea where to check if that is enabled, I do not see it in utorrent Preferences.

- I have always just right-clicked and gone to remove and delete data or remove and delete data and torrent.

[moogly]

-I don't know what you mean by this, but when I scroll over the Red X in the toolbar, it says remove.

It's the shortcut 'Remove' in icon toolbar. Right click on it and you can choose the action (Remove, Remove and delete etc...)

-I have no idea where to check if that is enabled, I do not see it in utorrent Preferences.

Same thing, right click on Remove icon and check if this option is enabled.

[jig]

just to note, I've seen this issue quite a bit because I use an old machine as a torrenting box.

I believe the source problem is sound card drivers, usually coupled with low memory. When you delete torrent+data, utorrent calls out to the system to create a default sound event - the particular sound is dependent on what desktop theme you've chosen, unless you've customized it. The problem is two fold:

1) If you're low on memory, and you have somewhat bulky sound card drivers (the worst is probably sound blaster, but all manufacturers are susceptible), the drivers don't stay resident in memory and get swapped out to disk. So, when you select "delete torrent+data", utorrent makes a system call for the default sound, the sound drivers have to be swapped back into memory, and then the sound can play, and the delete goes through. Getting the drivers back from disk cache can talk a LONG time if you're already thrashing your swap hard drive with, for instance, heavy torrenting. It also takes a long time if you have a lot of things running and taking up your physical memory because something has to be swapped to disk BEFORE the drivers can be swapped to memory. Similarly, not only do the drivers have to be resident, but the sound itself (usually a wav file) needs to be resident. If you've customized your theme to have some strange, large sound file as your default sound, you could be geometrically increasing the hang time.

2) In particular, sound blaster cards have some issues with IRQs and the PCI bus (many other manufacturers do as well, but today I'm picking on sound blaster). Whatever the issue is, there's a hiccup in the driver calls, and whatever sound blaster or Microsoft did to bugfix causes further issues with the PCI bus, and this THEN causes all data transfer on the PCI bus to stall. It seems to be somewhat dependent on memory load, so my guess is that the patch code is some large chunk of unoptimized object code that needs to be swapped, and is large enough to really make the whole system buck and whine. And, I bet it takes over the whole bus to figure out how to fix the issue. The Point: if you have a sound blaster card in an old system, this may be a large part of your problem.

Possible solutions:

You can try muting the computer sound. At least on some systems, the system calls to sounds gets cut off early, and non of the bus contention/memory swap issues happen.

You can also try just getting rid of your default sound in the sound settings. Leave it blank. That way you'll still have sound generally, but the utorrent call won't do anything (again, may be OS dependent).

If you've customized your default sound, I'd revert back to something simple.

Some sound cards have alternative drivers. There are alternative sound blaster drivers, at least (someone reverse engineered some).

You can take out your sound blaster (or whichever) card and try it in a different pci slot. It shouldn't make a difference on, for instance, an old i815 chipset motherboard, but it does. Sound blaster in particular didn't implement irq sharing or plug and play properly, so their cards' irqs are at least somewhat dependent on which PCI slot they're installed in. If you choose the right slot, problem #2, above, won't be an issue. Best bet - try different slots to see if the system works better. Downside - time consuming.

You can remove the sound card completely and use the on-board sound (if you have one). Those drivers are USUALLY smaller and better, though the sound quality might not be the best.

Finally, you can just remove the card and the drivers to test.

One possible NON-invasive way to test if this is your issue - figure out WHEN the default sound is played when you delete torrent + data. If it's only played AFTER the hang, my guess is that the problem is #1 and/or #2, above. If the sound plays first, and then you hang, then the issue is something else. From what I can tell, the default sound gets played when the "are you sure?" box pops up after you've selected "delete torrent+data". That means that the delete hasn't happened UNTIL you hear the sound and click ok. So, if it hangs before sound, then it's probably the sound call (or maybe the system call itself - to get the popup to pop). If the hang is after the sound, then you've ruled out the system call, and I think you're left with the delete process itself - which can be subject to memory issues and bus contention as well (especially if you're "moving to the trash can" on an old system.

IF the hang still happens BEFORE the system call/default sound, even after you've muted sound, removed card, etc, then utorrent has got to have an issue with how it makes a system call. Maybe it's a non-threaded call in a strange loop, or maybe it IS threaded, but has a wonky bug that only shows up on older, non hyperthreaded or multi-cpu machines, especially ones that are low on physical memory. Note - I'm not sure how you will tell if the hang comes before or after the sound with the sound card removed - I guess you'd have to watch the pop up and see if something strange is going on with it, like maybe the "ok" button doesn't highlight immediately.

Anyway, hope that helps. If utorrent had a way to turn off the system call for sound and/or the pop up(does it?), then maybe that would solve the problem.

Post back if none of this works for you. I'm interested in other possible causes.

Edit --> forgot to mention that sound card drivers and 64-bit computing seems to have it's own world of bugs. I'd bet that while it's probably NOT an IRQ issue with an i7 and a new motherboard, it could very well be some other issue with the sound drivers. Always be sure to have downloaded the latest (if you're already having problems).

[SmartWater]

Default is remove, and remove to trash if possible is ticked. Both computers I've had this problem on, I use standard integrated sound with standard drivers. I had 2GB ram on the core2duo vista 32bit and I have 6GB ram on the i7 vista 64bit.

[Honeyfrog]

This bug is back with a vengence in 15728. It is *definitely* related to gui.delete_to_trash -- with it turned on (default), uTorrent sat froze solid for over half a minute on an 800mhz P3 laptop despite the fact that absolutely nothing else was going on at the time (no DLing, no other programs running, no activity in TaskManager, etc) and that the torrent in question had already had its files deleted manually ahead of time (i.e., uTorrent was only being asked to delete files which were already non-existent). This freeze behavior was identical if I rechecked the torrent of manually-deleted files, then went to remove/delete.

When I turned gui-trash OFF, then there was no freezing, and removal was instantaneous.

[SmartWater]

How do you turn gui-trash off exactly?

[moogly]

Preferences > Advanced > gui.delete_to_trash = false

[thegood]

It is *definitely* related to gui.delete_to_trash

I can confirm that this bug is indeed related to gui.delete_to_trash. In my case, I think I know exactly why it behaves so.

My uTorrent download folder is set on a hard drive which is mounted as a path on another hard drive. This means that instead of my uTorrent hard drive having a letter (like C:, D:, etc...), it has the path C:\Downloads, where C: is my other (primary) hard drive.

Because I had "Remove to trash if possible" checked, when I attempted to delete torrent+data, uTorrent would actually MOVE (ie. copy and then delete the original) the downloaded data from the secondary disk (where the uTorrent folder is) onto the primary disk so that it could go into the Recycle Bin. This is the expected behaviour because the secondary (mounted) drive doesn't have a Recycle Bin of its own.

I don't know if this is what's also affecting you Honeyfrog, but in my case, I think this is why uTorrent was "freezing up" everytime I did torrent+data (imagine waiting for 4 GB of data to be copied without having any indication that it is doing so). Unchecking "Remove to trash if possible" did fix the problem.

[Ultima]

Indeed. I'd forgotten that I had once identified removing to the Recycle Bin as the root cause of the problem over two years ago, which is why I asked again up above.

The devs are also aware of the problem, but unfortunately, it's much easier to talk about a solution than it is to actually come up with one. For the technically initiated, removing to the Recycle Bin in Windows is performed through the SHFileOperation() Win32 API. Apparently, though, Microsoft had the brilliant idea to design the function such that it has to run in the application's main GUI thread (according to the devs, attempting to delete files to the Recycle Bin on a separate worker thread caused µTorrent to crash instead). The result is that deleting large amounts of files to the Recycle Bin causes the entire application to lock up.

The previous solution the devs came up with wasn't really a solution -- it was just a workaround that basically deferred file deletion so the lockups weren't in the user's face.

Note: I myself am not particularly familiar with using SHFileOperation(), so there may well be a way to get it to work on another thread. From simple Googling, though, it seems like many people say "use it on a separate thread if you don't want it to block your main thread", but no one ever actually explains how they'd go about doing so, or whether they've tried it with success themselves before.

[thegood]

For the technically initiated, removing to the Recycle Bin in Windows is performed through the SHFileOperation() Win32 API. Apparently, though, Microsoft had the brilliant idea to design the function such that it has to run in the application's main GUI thread

Well, it's probably because they didn't think moving files to the Recycle Bin could take very long (which it doesn't, since a move on the same hard drive is very fast). Obviously, my case was different because it actually had to copy the data.

Maybe uTorrent should give a warning upon deleting if it sees that it will have to transfer data?

[Ultima]

a move on the same hard drive is very fast

Obviously not, because this lockup happens regardless of what drive you're deleting from. Moving between drives is not the cause of the lockups.

And assuming the function will be fast enough isn't really a valid justification or reason to make it such that a function can't be called from outside the main thread. SHFileOperation() comes with a progress bar dialog that can be disabled. If the progress bar were shown, it would at least make some sense that it'd need to be tied to the main thread, but if the dialog were disabled (as it is in µTorrent), there's no reason why it should be that way at all.

Edit: Oh, and as far as I know, each drive has and uses its own dedicated/reserved RECYCLER directory -- further reason to believe that a copy operation between drives is not the cause of the problem. Everything just shows up under one "virtual" shell directory known as the Recycle Bin (otherwise, why would there even need to be any Recycle Bin properties on a per-drive basis?).

[OZZIE]

If Windows actually only allows the GUI-thread (or top layered thread) to move files, a simple solution would be to start a new light "application" that appears to windows as a "GUI-thread" and have that move the files. This gui could have a simple text saying "moving files to recycle bin" or so.. and the user can simply minimize this window and when it's done it could just close it-self. Would look a lot similar to moving files in windows..

Edit: Since this would be its own process, if it locked up it wouldn't cause utorrent to crash or the user to have to force utorrent to terminate, you could just terminate the moving files process. I think it would be a slick solution to a "crappy problem", damn microsoft..

[DarkByte]

Hello everyone,

I just bumped into this problem myself in a program that I'm writing. However, I need to copy some files (one at a time) and recycle the destination files (if they exist) - so the threaded solution wouldn't do much good for me, unless I make a list of all the files that need recycled, thread the deletion, wait for the thread to finish and then go on about my business. That would require a lot of work (my program is quite large) and I'm not sure that it will work.

I'm currently pursuing another approach to this "delete to recycle bin" thing that may be of help for you. Recycle Bin is a virtual location, using, practically, a special directory for each partition you may have. If one could get that location for the specific file(s) that must be deleted, the code could be modified to use MoveFileEx instead of SHFileOperation. Moving a file to a new destination (but on the same partition) should be a lot faster than using the SHFileOperation (which MS turned into s*#t).

After some research (very little) on this idea, I found the following link : http://stackoverflow.com/questions/936397/finding-the-recycle-bin-on-a-local-ntfs-drive ...

I'll let you know how it goes.

L.E. unfortunately, although I got the correct Recycle Bin path for the specific partition, it's not enough to just move the file there. The file is moved into the Recycle Bin with another name (random, from what I could see) and the system also creates a new file (random name, but same extension) to hold the data about the file (size, original path and, presumably, the file's modified date) - a name tag, so to speak. However, I'm not sure of the exact file structure of the name tag file - i know where the size and the file path are hold, but there are a few more bytes in the file which I didn't quite figure out.