No Seeders? Not Always the Case! How to Revive a “Dead” Torrent

Just because that hard to find torrent can’t seem to find any seeds to download from, does not necessarily mean that there are 0 seeders available in the entire world!

Seeders are very important users to you, as they are the users with a complete version of the file you are seeking. So it makes sense in desperate times to search additional trackers when you are having a hard time tracking down some seeders!

Here’s where adding trackers from our Tracker List come in handy. What this allows you to do is check other trackers (that were not included in your .torrent file) to see if anyone else has the same file to download.

This is a huge benefit as it can help you:

• Track down and increase seeder counts for a file that had none, so that you can begin downloading it
• Add to your current amount of seeders to increase overall download speeds

You must keep in mind, that this situation will arise pretty rarely and may not always work, but if you do find yourself having a tough time finding seeders it’s definitely worth a shot.

Here’s How!

Bittorrent / uTorrent

For Bittorrent 6.4 and uTorrent 2.0 alike you can click on the torrent you are downloading and then select the Trackers tab at the bottom, right-click and select Add Tracker.

As you can see by the image above, we are having a bit of a hard time finding seeds for our torrent…
In the next window, just add the trackers you want to add into the the trackers box and be sure to keep them separated by a line.

Hit OK, and you should see them added into your Trackers tab now, and your client should begin searching them.

And would you look at that! We’ve found some Seeders!

Deluge

In Delgue, once the torrent is loaded right-click on it and goto Edit Trackers. Once inside you are given the option to Add trackers. After you have added all the trackers you desire, right-click again on the torrent and select Update Tracker.

You can find a long list of trackers on our Tracker List page.
Happy Hunting! ?

Join the forum discussion on this post - (1) Posts

Recent coverage of uTP on the popular Torrentfreak blog yielded some interesting feedback in the comments section.

There are a couple of misconceptions that I’d like to address here:

First is the idea that we designed uTP *for* the ISPs. It was not.

While we think there are substantial advantages for ISPs in the broad adoption of uTP, the protocol was actually built from the start as a way to help consumers themselves. The fact remains that when using TCP, a poorly tuned BitTorrent client may well result in an internet connection that habitually gets congested and then drops packets, then recovers and repeats the process. This is not good for anyone.

The second misconception is that uTP will somehow slow uTorrent down. This is also not true. It will certainly result in less headaches for everyone and it may even speed things up.

Our design objectives were always to leave transfer rates unchanged, and we’re still confident this is achieveable. The fact that you don’t have to manually “manage” your client or limit it to some arbitrary % of your connection should mean that in practice it will be reliably faster. What’s more, we may actually be able to make it go faster than an unlimited TCP BitTorrent client. The way to picture this is to consider cars on a highway: you can only drive at 90 mph if there’s not much other traffic. But if there’s a lot of traffic then quickly the whole system will snarl up. uTP is designed to make clients transfer at an optimal speed *without* causing a snarl up. The thrill of speeding along at 90 mph is rather lost if you keep having to slow to a crawl until things recover. By avoiding this “stop/start” we felt that uTP *should* make things go faster overall.

Early evidence is starting to come out now from researchers at the University of Washington who are performing some independent tests on uTP performance. (These results are NOT conclusive at this point, but the early indications are quite good…)

From the first graph below you can see the interaction of uTP traffic (green) with some other application competing to use the connection (red). As expected, the uTP traffic backs off immediately and is replaced by traffic from the competing application – upon completion of the competing transfer, the uTP BitTorrent traffic quickly resumes. The blue data points represent the uTP traffic holding steady against the (right vertical axis) target delay of 100ms (I’d note this is vastly lower than anything achievable with TCP BitTorrent transfers).

The uTP controller is clearly doing its job, spotting a different application trying to use bandwidth and getting out of the way, only to recover just a fast.

But in many ways the more important graphs are the following…. These show you that uTP BitTorrent is just as fast as best-case TCP BitTorrent, and may even be faster…

Now one likely explanation for this is that the uTP overhead (a few % of the traffic which is not actual content) is included, but the TCP measurement excludes it. If this were true then probably uTP and TCP are almost identical.

But if we find that uTP traffic is indeed faster than TCP BitTorrent traffic, there are a couple of reasons why this slightly surprising conclusion might indeed be true –

Either the stop-start nature of TCP-based BitTorrent creates inefficiencies that are being optimized away using uTP.

Or else there were ISP network management measures in place which were discriminating against TCP-based BitTorrent.

Or possibly the UDP NAT-traversal techniques introduced along with uTP were resulting in far more good peers with uTP.

Or possibly something else?

Whatever the reason, this is early evidence that uTP is an even bigger win for consumers than anticipated, as well as being a positive contribution to ISPs.

Much more work remains to be done, but this is exactly the type of result we’re hoping to see more of.

–Simon–

We’ve spent a lot of time in recent posts talking about the benefits of µTP.  We’ve even talked a little bit about how it works here, though much more so in the various technical forums for the community.  But sometimes a picture is worth 2^^10 words and I think the graph below says it best.  µTP appears to be up to the task of reducing congestion.

These results are taken from our QA regression tests that we run on each new version of the client that ships with µTP.  The test is a simple one.  We use a DSL line here in the office and start a client seeding on that DSL line.  We then measure the latency seen by other applications, such as VoIP, online games and web browsing, that we run concurrently over the same link.  The graph above is a histogram of those latency samples.

The green samples were taken with a client seeding on TCP and the red samples were taken with a client seeding on uTP.  (You can tell that these are engineering graphs rather than marketing ones simply enough by the fact that GREEN= bad and RED = good, but you get the picture…).  In reading the graph, remember, queuing delay (latency) is a side effect of congestion.  More latency in this test means more congestion.

With the target latency set at 100ms, µTP does a pretty good job keeping the latency felt by the other applications near the target.  TCP clearly does not and more than congests the uplink.  In the process this ruins the network for all of the adjacent applications below.

While much work remains ahead of us (like picking the right target latency), it seems that µTP demonstrates some clear potential to alleviate network congestion wherever the network bottleneck happens to reside.  This has obvious benefits for users who will no longer congest themselves, benefits for publishers who want to use BitTorrent but also want to protect their brand when users seed content on their behalf, and benefits for ISPs who should see far fewer support issues with BitTorrent causing congestion and impacting other users on the network.

A win win win.