Auto recheck & auto refresh

[shekel20]

Now and then, I got uTorrent finished downloading but I got CRC about one of the files or so.

As I re-checked the torrent, I saw that several of the files are just 90-99% completed.

In clients like bitcomet, you can make sure that everything's ok like that. uTorrent will auto re-check the torrent to see everything's ok and if not, continue downloading what's necesery.

Also to have an option that the tracker will auto-refresh in a period of time that can be modified.

Of course this option could be enabled or disabled.

Thank you.

[Firon]

The tracker update interval will never be user specifiable because the tracker specifies that interval.

[DaSmith]

I'm sure that this is not true! I used BitComet before but switched to uTorrent, cause everybody said that it is much lighter, and I don't have a very powerful computer. I really like uTorrent but saying that the tracker update interval is specified by the tracker is bull****! How come then for the same tracker in BitComet the update interval was 5 minutes and in uTorrent it is 30 minutes?

[splintax]

Because BitComet doesn't respect the tracker.

[Nefarious]

one of the many things why bitcomet is banned in most of the trackers

@Dasmith:

u may have been using only one tracker for everything, if u use many trackers u will see different times for update 30minutes being the most common, but i've also seen some going down up to 5mins

[Firon]

you'll see something similar to d8intervali3600e in the tracker response.

[DreadWingKnight]

but saying that the tracker update interval is specified by the tracker is bull****!

No it's not

http://wiki.theory.org/BitTorrentSpecification

Tracker HTTP/HTTPS Protocol

The tracker responds with "text/plain" document consisting of a bencoded dictionary with the following keys:

* failure reason: If present, then no other keys may be present. The value is a human-readable error message as to why the request failed (string).

* warning message: (new) Similar to failure reason, but the response still gets processed normally. The warning message is shown just like an error.

* interval: Interval in seconds that the client should wait between sending regular requests to the tracker (mandatory)

* min interval: Minimum announce interval. If present clients must not reannounce more frequently than this.

* tracker id: A string that the client should send back on its next announcements. If absent and a previous announce sent a tracker id, do not discard the old value; keep using it.

* complete: number of peers with the entire file, i.e. seeders (integer)

* incomplete: number of non-seeder peers, aka "leechers" (integer)

*

peers: The value is a list of dictionaries, each with the following keys:

o peer id: peer's self-selected ID, as described above for the tracker request (string)

o ip: peer's IP address (either IPv6 or IPv4) or DNS name (string)

o port: peer's port number (integer)

Bitcomet just ignores it because it's that flawed.