Jump to content

GCRaistlin

Established Members
  • Posts

    101
  • Joined

  • Last visited

Posts posted by GCRaistlin

  1. 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. For those who, for some reason, needs to manually change status of some torrent in resume.dat:

    • From Stopped (0%) to Finished (100%):

    1. have parameter:

      1. Change type from "Binary, as Binary" to "Binary, as String" (data loss is OK).
      2. 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.
      3. order parameter: set the value to -1.
      4. valid parameter: create with Integer type, set the value to 1.


      5. 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. rechecking is semi broken in several ways

    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. What are the EXACT steps to reproduce this behaviour?

    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. 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.

  6. 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.

  7. 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:

    1. 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.
    2. Both 2.2.21738 and latest builds took hours to close correctly (I have almost 5000 torrents in list). v1.8 closes in seconds.
    3. 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.

  8. 2.2.21738. It's the last build that:

    - does NOT check for availability of files for torrents with "Finished" status;

    AND

    - does NOT have "Disc overloaded 100%" issue on Win2k3.

    BTW - modern versions have both of these issues: in latest builds, if the drive files of the torrent with "Finished" status were allocated on doesn't present in the system anymore, the torrent will get erroneous status (which is bad). 2.2.21738 ignores anything related torrents with "Finished" status (which is good).

  9. Let's assume that we have completed torrent named "Torrent1" in C:\Torrent1. We stop it (status changes to Finished), then rename C:\Torrent1 to C:\Torrent2, then rename torrent from "Torrent1" to "Torrent3", then try to start it again. Its status changes to "Moving..." and that's all.
    Sorry my bug report wasn't precise. Status changes to "Moving..." after we change download location to C:\Torrent2 (download location hasn't been actually changed at that - on Info tab we're seeing old location). After pressing Start status changes to "Invalid".

    I should add that then I have tried to stop the torrent, renamed torrent to "Torrent2" and changed its location to C:\Torrent2. Its status remained "Moving..." - I was forced to restart uT to change it. After I did that I discovered that torrent's content was finally moved to C:\Torrents3. But anyway, why its status was "Moving..." for so long? The old and new folders are both on the same logical drive.

  10. Let's assume that we have completed torrent named "Torrent1" in C:\Torrent1. We stop it (status changes to Finished), then rename C:\Torrent1 to C:\Torrent2, then rename torrent from "Torrent1" to "Torrent3", then try to start it again. Its status changes to "Moving..." and that's all.

×
×
  • Create New...