Established Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About GCRaistlin

  • Rank
    Advanced Member
  1. GCRaistlin

    BEncode Editor

    zalta999 resume.dat doesn't contain any hashes, they're stored in *.torrent (which you can open with this tool, too) instead. Actually, you perhaps didn't need to delete any torrent from your resume.dat, it would be probably enough to just save it after opening.
  2. GCRaistlin

    BEncode Editor

    For those who, for some reason, needs to manually change status of some torrent in resume.dat: From Stopped (0%) to Finished (100%): have parameter: Change type from "Binary, as Binary" to "Binary, as String" (data loss is OK). Set the value to ANSI chars of code 223 (Cyrillic "я"); their quantity should be equal to the length of the parameter. One way to get this char is to copy it from the corresponding parameter of another torrent with Finished or Seeding status. order parameter: set the value to -1. valid parameter: create with Integer type, set the value to 1. From Error: file missing from the job, please recheck (100%) to Finished 100%: started parameter: set the value to 0. MAKE A BACKUP BEFORE EDIT!
  3. That's just the point. A lot of basic things are broken in v2 and even more in v3 - in comparison with v1.8. Instead of fixing them developers are occupied with (relative) exotic things like magnets, RSS and so on.
  4. Open torrent in uT ([ ] Start torrent) pointing it to the dir with incompleted set of files, right click on it, select Force recheck. I have no idea why uT thinks that it should start the torrent after recheck.
  5. Another bug in 29569: after rechecking unfinished torrent being in Stopped state uT starts downloading it. It should remain in Stopped state, shouldn't it?
  6. Do they still support XP? I believe yes. Why then not to support Win2k3? And why not to fix this introduced since v3 bug? I didn't check yet the second epic (for me) bug in v3 - '&' in a label makes it unremovable. Just 'cause I can't even correctly exit uT - for a hour or so! Why am I sure that it's still there? It's time to run old good v1.8 again. v3 doesn't seem to become usable.
  7. The same old Win2k3 problem in 29569: Disk overloaded 100%.
  8. danei, thanks, you made it clear. But hours is anyway too much.
  9. Zarggg, your "should" looks nice. Is there any official limitation to the number of Finished torrents in the list? And who talks about using uT as a file manager? I found just comfortable to use uT the way I do.
  10. Keldin, because I use torrent list as the second ("reserve") catalogization tool (the first one is WhereIsIt). When torrent is downloaded I rename its folder and its name in torrent list to the name of its topic on the tracker. This allows me to quickly determine later if I downloaded the particular torrent before (WII is very slow). Also, when I downloaded a new version of a movie (of higher quality) I marked old version as "to be deleted" both in WII and in torrent list using the label (I may not be able to delete it at once 'cause it might be stored on stand-alone HDD - I have about 20 of them for now). Why both - because, on the one hand, I don't want to delete torrent that I still have from the list, but, on the other hand, I don't want to leave it in the list after I deleted it. I may forget to delete it from the list after deleting it from the HDD - "To be deleted" label will remind me to.
  11. dubnium, well, maybe later I'll try to. But what will it show? Let's assumed that without Finished torrents v2 will close as fast as v1.8 - and what? 4 hours is what I remember for sure.
  12. dubnium, "5000 torrents in list" doesn't mean "5000 active torrents in list". Most of them are Finished.
  13. As I wrote above, I was using uT 2.2.21738. A couple of weeks ago I have tried version 1.8 - and now I'm using it: I've never seen download/upload statistics like "5.0 Mb download / 1.8 Mb upload" - neither in latest builds nor in 2.2.21738. No I don't mean that uT never downloaded or uploaded at this speeds - but not simultaneously: if download speed was high, upload speed was low; if there's currently no download in progress then upload speed was high. I was pretty sure that it's hardware limitation - unless I've tried v1.8. Both 2.2.21738 and latest builds took hours to close correctly (I have almost 5000 torrents in list). v1.8 closes in seconds. Because of smaller font and/or icons in v1.8, more torrents (and columns) fit in torrent list - even in comparison to v2, not to mention v3.