Honeyfrog Posted July 5, 2007 Report Posted July 5, 2007 Dragged-n-dropped in a torrent, hit OK on the save-wherever dialog, then realized that the save directory was wrong, and immediately hit red-X. Then I dragged-n-dropped again...and got "The torrent you are trying to add matches a torrent currently being deleted". Wait; try again. Same error. Wait; try again. Same error.It took more than twenty seconds for the darned alert to stop appearing.(I don't have pre-allocation, and I hadn't downloaded anything from any peers before "X"ing.)
Richard Choi Posted July 5, 2007 Report Posted July 5, 2007 In the past, the entire program would have frozen for those 20 seconds... the deletes are now done asynchronously, and those warnings are there to prevent some real nasty things that may happen if you re-add a torrent waiting to be deleted.
Honeyfrog Posted July 5, 2007 Author Report Posted July 5, 2007 I'm curious why it has to "wait", given that there wasn't anything there to delete in the first place because I hadn't downloaded anything yet. I hadn't even connected to any peers yet. I don't have pre-allocation enabled.
Richard Choi Posted July 5, 2007 Report Posted July 5, 2007 We clean up all torrent state (eg properly disconnect from trackers) before deleting our internal data and all the data files. This could possibly be optimized for future builds.
Honeyfrog Posted July 5, 2007 Author Report Posted July 5, 2007 I don't recall the twenty second delays in 1.6. (And I did just hit X; I didn't ask it to remove & delete files.)
Richard Choi Posted July 6, 2007 Report Posted July 6, 2007 Ok, just looked into this some more. The warning was added to handle really bad cases with the asynchronous deletes (which is probably not the case for you), but also makes sure that you properly disconnect from trackers before connecting again with the same infohash, which is probably a good idea, although not doing so wouldn't be catastrophic. On the bright side, while looking at this, I found a simple optimization that could speed up deletes for those that delete .torrent and/or data =)
Ultima Posted July 6, 2007 Report Posted July 6, 2007 @Honeyfrog: Several people experienced delays when deleting torrents in 1.6 (myself included), so it was a very real problem. The interface simply hung for a long period of time, and it looked like it froze.Edit: Richard's optimization should have made it into RC4.
Honeyfrog Posted July 6, 2007 Author Report Posted July 6, 2007 (Testing using RC4 now. Problem is easier to notice when testing a torrent with lots of trackers, like a dozen or more.)The warning was added to handle really bad cases with the asynchronous deletes (which is probably not the case for you), but also makes sure that you properly disconnect from trackers before connecting again with the same infohash, which is probably a good idea, although not doing so wouldn't be catastrophic.Presently, uTorrent takes longer to X-out a single torrent that it does to quit entirely (at least far as the TaskManager is concerned) from a state or over a dozen torrents actively trading. (Does quitting just "heart-attack" the connections?)
Ultima Posted July 6, 2007 Report Posted July 6, 2007 Quitting forcefully exits everything if it doesn't finish within 10 seconds after the user requests for the application to exit, that is, unless bt.graceful_shutdown is enabled, in which case it can take forever (it'll wait for a bunch of stuff to finish and trackers to respond properly before fully exiting with that option on).Regarding the RC4 link I posted, I'm not really sure if it contains the fix, as the linked version is only build 3166, and IINM, Richard's change should've been incorporated after that (as the changelog shows, by build 3170).
Honeyfrog Posted July 6, 2007 Author Report Posted July 6, 2007 Could we link the X-out and delete behaviors to the default shut-down behavior (i.e., the ten-second rule), unless bt.graceful is enacted? I think that would handle the problem nicely.
Richard Choi Posted July 6, 2007 Report Posted July 6, 2007 My aforementioned fix did not handle Honeyfrog's specific case, but it was something I noticed while looking at the code. Typically, the disk cleanup takes longer than the tracker cleanup, but in some cases (like with many trackers), the tracker cleanup can take longer. My fix was to allow file deletes before the tracker cleanup is completed.For Honeyfrog's case, I have just checked in a change that will allow you to re-add a torrent that was just previously for delete, as long as you aren't waiting for disk operations with that torrent.
funchords Posted July 6, 2007 Report Posted July 6, 2007 One of the frequent Vista complaints is that it takes much longer to delete files than it did on XP. I don't know what the root cause of that is, I don't run Vista.In the absence of any hard information, I suggest that Richard's change needs to be well tested on Vista.
Honeyfrog Posted July 6, 2007 Author Report Posted July 6, 2007 Thanks, Richard; let me know when it's posted.
CodeRed Posted July 11, 2007 Report Posted July 11, 2007 One thing that can happen is that you begin downloading a large file, like 1GB or more. Unless you have sparse files enabled, the first write to the file will take a LONG time since Windows needs to go off to fully allocate it. If you try to quit in this time interval the process will be in a complete limbo, the kernel won't let it terminate until the write is finished. If you try to start another instance of uT it will detect the previous one and refuse. You also won't be able to kill the process from task manager, or at all in any way. If you start a torrent, then quickly remove it while Windows is doing the allocation the deleted torrent is stuck waiting before it can really be removed. While in this state you can't add it again, at least not with the same infohash. Terminating uT won't help either - the process will still be in End Now Hell.
Honeyfrog Posted July 11, 2007 Author Report Posted July 11, 2007 One thing that can happen is that you begin downloading a large file, like 1GB or more. Unless you have sparse files enabled, the first write to the file will take a LONG time since Windows needs to go off to fully allocate it.And that's another reason I want this l'il baby right here: http://forum.utorrent.com/viewtopic.php?pid=258475If you think 1GB is a killer, uTorrent can and will choke/Error while allocating a full DVD9 iso, to say nothing of a complete 24gig HD project. :-PQ. If sparse files _and_ first/last are simultaneously enabled, will full-size files still be pre-allocated? (I gotta have first pieces...last ones I could care less about, since about the only files that save important crap at the end are Microsoft junk like .wmv formats that no self-respecting ripper uses.)
Richard Choi Posted July 11, 2007 Report Posted July 11, 2007 I believe the latest RC should have a change that is designed to speed up your specific case of deleting something with lots of trackers. You should be able to re-add the torrent significantly faster now.
Ultima Posted July 11, 2007 Report Posted July 11, 2007 Odd that it wasn't in the changelog though :/
Honeyfrog Posted July 12, 2007 Author Report Posted July 12, 2007 Thanks, Richard. Here's one thing you may wish to look into, however:1. Start up a torrent with a dozen or so trackers (more the better, esp. if some bad).2. Let it run enough to allocate some files.3. Now remove+delete.4. Immediately click the minimize tab.--uTorrent acts like it's frozen for about five or ten seconds or so. Appears to be harmless, but it's disconcerting if you want your window space back pronto. (This may not be noticable on newer machines, but it's obvious on a Pentium III.)
Recommended Posts
Archived
This topic is now archived and is closed to further replies.