Set New Download location for many torrents fails to work, causes prob

[lovetour]

uTorrent v3.2.3 build 28705 (I can't update to 3.3 yet or alpha/beta due to tracker policies)

Drive setup:

(A) One internal drive with OS, Software, uTorrent executable, ".torrent" files, swap, etc.,

( One internal drive with torrent downloads on it, and

© One USB 2.0-connected external drive with torrent downloads on it.

(D) One USB 3.0-connected external drive with torrent downloads on it.

Task:

I need to move large amounts of data from downloaded torrents from from drive both ( and from © to the fastest external drive, (D).

Since uTorrent can move files and keep torrents targeted to the same files in one step (Advance/Set New Download Location, or Relocate for individual files), I wanted to take this efficient approach - use Set New Download location for my many torrents.

Initial uTorrent upload/download state during testing:

Initially I was seeding some files with an upload limit, including overhead, set at 45 kB/s. No downloads were occurring. DHT was disabled. Disk Cache Settings as follows: Basic Cache Settings both unchecked (no cache size override, no memory use reduction when cache not needed); Advanced Cache Settings all checked (auto-increase read cache size and remove old blocks enabled, amongst the other advanced settings).

Initial Testing and Results:

(1) Set New download Location (henceforth referenced as "SDL") for a "Finished" torrent of about 10GB size from drive © to drive (D) (Drives as described above). Result: Upload activity dropped to 0-1kB/s during move, but the move worked fine and as expected. After the files were moved, upload activity went back to normal.

(2) SDL for two torrents each 12-16GB in size, both from drive © to (D). Two concurrent moves of about 25-30GB data. Result: Same as for (1) -- Upload activity dropped to 0-1kB/s during move, but the move worked fine and as expected. After the files were moved, upload activity went back to normal.

Expectation v. Initial Results

SDL worked for moving multiple (tested up to two) large torrents at once (good), but interrupted uploading (bad). My expectation is that torrenting activity should be higher priority and file moves should be background tasks. Torrenting should always continue as normal, even if it means file moves take longer. By the way, there was never any "Disk Overloaded" message in the status bar. Even with the priorities as they seem to be (disk moves higher priority than transfers) -- if disk bandwidth was at issue, I would expect an "Overloaded" message since there is one.

Round 2:

I started downloading 2 torrents, with speed capped at 200kB/s. Destination disks: Drive © for one and (D) for the other. Still seeding at 45kB/s.

I was encouraged that SDL seemed to work fine for multiple (tried 2) large torrents simultaneously, so I decided to go ahead and move a larger batch of torrents.

Round 2 Testing and Results:

(1) Moved a few more torrents one at a time, with the same results as in round 1, except now I can see that download activity also came to a virtual halt at 0-10kB/s.

(2) SDL for 38 torrents of 300-400MB each (about 14 GB total) from internal drive ( -- the fastest drive involved to drive (D), the second fastest drive involved (USB 3.0). Upload and download activity came to a virtual halt as before.

(3) Concurrently SDL for a couple more torrents of 10-12GB each (about 22GB total) also from drive ( to drive (D). Total of about 40 torrents and 36GB in concurrent SDL now. Upload and download activity came to a virtual halt as before.

(4) "Disk Overloaded 100 %" message in status bar this time. "Moving" state for some torrents continued indefinitely (left going for over 14 hours!) and for other torrents eventually went back to "Finished" or "Seeding" (but for some torrents, only some files were moved, and for other torrents no files were moved at all. In no case were any torrents successfully moved in entirety.)

Expectation v. Round 2 Results

This was a complete failure... I expected the torrent files to be moved and upload/download to not be effected, ideally. I wasn't surprised after round 1 that upload and download came to a virtual halt, but I was surprised that all 40 torrents failed to be moved. After 14 hours, uTorrent still indicated "Disk overloaded 100 %" although the process had 0 disk activity for the bulk of the test time (verified in Task manager). After 14 hours, uploads and downloads were still at a near halt. All but one of the torents I tried to move was no longer in a moving state, but had returned to "Finished" or "Seeding". Well, one of them went on to "Error: Files Missing From Job". At least one torrent (still trying to sort it out) had a few of it's files moved, but not all of them, and the download location updated to the new location on drive (D), although most of it's files were left on drive (. Most or all of the other torrents failed to move any files at all -- all files were left in their source directories on drive (. A couple download locations were updated to the selected drive (D) location, despite no files being moved. Most download locations were left to reflect their original location though, at least consistent with no files being moved. A the end of the test (14 hours) just one torrent was still in the "Moving state" (with only the same few of it's files moved that were moved 12 hours ago), but I think I restarted that move a couple hours into the test when uTorrent had put it back in a "Finished" state already with only a few files moved. Also at the end of the test, uTorrent still indicated "Disk overloaded 100 %", despite little to no disk activity by the process. Furthermore, uploads and downloads were still at a virtual halt. OS access to drive (D) is extremely slow, despite virtually no disk activity. Switching folders in Windows Explorer takes 10-15 seconds. The uTorrent process took about 4 minutes to close (File>Exit). After several seconds, the window was hidden, but the process remained running, with CPU usage quickly hitting 0%, no disk usage, and memory usage unchanging for most of that time, although the process did finally close after about 4 minutes (I imagine it gave up on doing all of it's shut down tasks by then). After uTorrent exited, the system was still in a bad state: Accessing drive (D) was so slow as to be nearly impossible. When I then attempted "Safe Removal" of drive (D), the process attempting to set the drive for removal hung. When I attempted to close a Windows Explorer window with a view of drive (D), Windows Explorer hung. After killing both processes and restarting Explorer, I tried safe removal of the entire USB 3.0 hub (ExpessCard device) that drive (D) was connected to. No success or failure after several minutes and Safe Removal task is again unresponsive. Forcefully removed USB 3.0 hub and with it drive (D). After several minutes, no messages from Windows indicating it noticed, and drive (D) still listed in Windows Explorer. After several more minutes, finally a message "Drive (D) is in use,. ...." as well as the drive disappearing from Windows Explorer.

My final situation:

I will reboot the computer, reconnect the devices, perform a checkdsk. I will reapproach the problem the more arduous way, but the way that I know to work: use Windows Explorer to move the rest of my files, and then point uTorrent to the correct locations.

My files were left in an inconsistent state, and my system was left unstable by uTorrent. Expected result: everything moved fine, system stable, no half-done jobs, file transfers unaffected, and no need to reboot at end .

Thanks for you attention and for an application that I find very useful.

~ lt

[lovetour]

Update: Part of the problem may have been hardware failure related.

The brand new USB 3.0-connected drive (drive "D") that was the destination for my file moves seems to fail sometimes under continuous heavy load (or is it the brand new USB 3.0 controller card...). Love those USB 3.0 speeds, but maybe they allow the drive to get too hot under continuous load... Anyway, if anyone tries to sort through the issues I described here, take that into consideration.

Some issues I described (such as the repercussions of file moves being high priority I/O) apply regardless of hardware problems. And drive I/O problems could ideally be handled in such a way as to not cause such instability, assuming that was indeed the case here.

Thank you,

~ lovetour ~