peers and seeds? v1.1.4

[eXtr4ktor]

Look at the number of peers in the list up top and look at the on at the bottom, its not reported to be the same, it didnt do that in 1.1.3, strange, not sure if its a bug or something.

[ludde]

This changed in 1.1.4

The value in the list shows the number of peers/seeds in utorrent's internal memory.

The value on the generals tab shows the values reported by the tracker scrape command.

[eXtr4ktor]

This changed in 1.1.4

The value in the list shows the number of peers/seeds in utorrent's internal memory.

The value on the generals tab shows the values reported by the tracker scrape command.

Ahh, thanks, should have read the changelog May i ask why it was changed though?

[eXtr4ktor]

I just noticed something, that third torrent in the screenshot shows 0 seeds in the general tab. From the info on the website, it should be over 920.

[eXtr4ktor]

Just found something else, tracker is reporting 5 peers but in the torrent list in uTorrent, its showing 25?

[vurlix]

Stale peers stay in memory for 30 minutes, which is probably what you're experiencing. Don't worry about it too much

[eXtr4ktor]

Stale peers stay in memory for 30 minutes, which is probably what you're experiencing. Don't worry about it too much

I had just started that torrent :/

[smyle]

Huhh, i writed a new bug topic what i not posted last....

so, my opinion is, very annoying if i see more peers at my seeded torrents in the main list, but noone connected and no upload in progress.

I methought its a huge bug in the transfer code.

So after this, im forced to see per torrent general tab for the real peers values :?

[eXtr4ktor]

Yea, i liked it more in v1.1.3 when i could see, quickly i might add, the number of seeds and peers for the torrent in question. This just confuses ppl alot more.

[myfear]

Ok, I love utorrent so far, but this change is really bad in my opinion :cry:

I want my 1.1.3 style back :oops:

edit: I could live with it, tho

[FreeBaseBuzz]

so was this peers/seeds issue a "feature" for this version or a bug.

Are you guy's going to implement a proper beta program and just use the automatic update for the official releases?

Do you concider the versions released to be beta's or offical releases?

I'm just curious, because I think this issue would have been picked up with any sort of beta test.

BTW, I don't mean to sound narky, I just type how I think.

I really do like uTorrent, it's a refreshing change from the memory hog that is azureus.

Don't suppose you'd concider doing a uBrowser to replace the memory hog that is Firefox

[vurlix]

It's not a bug. I wanted to separate the scrape and known peers info so it would be easier to identify some tracker problems. 1.1.4 is considered stable and is recommended for all users.

[segosa]

Ugh, I don't like this at all. I rarely look at the info in the general tab, and I'd like to get an idea of the amount of seeds and peers in the swarm by looking in the listview, like I did in every other client.

Isn't there a way to integrate both into that column? Maybe something like

2 (4) (S: 7)

where I'm connected to 2 out of 4 in the internal memory, and there are 7 in the swarm.

If not, maybe make it an option? It'll confuse a lot of people moving from other clients too if this is the default behaviour.

[vurlix]

1.1.5 should behave as you expect. (slightly differenctly, but the same idea)

[segosa]

Okay well, thanks. Though my suggested method was only a suggestion, you didn't need to implement it exactly in that way. It's my preferred one, but some other people might prefer 2 (4/7). I was hoping the rest of this thread would be people's suggestions to the best way of displaying it.

Thanks for listening though

[FreeBaseBuzz]

It's not a bug. I wanted to separate the scrape and known peers info so it would be easier to identify some tracker problems. 1.1.4 is considered stable and is recommended for all users.

Ok thanks, that clears it up a bit

Oh and the logger tab. I assume it's going to be utulized more in upcoming releases? I've had 1.1.4 going about 48 hrs so far on 2 different machines (different networks), and so far, all I've seen is "uTorrent Initializing"

Apart from those small gripes, uTorrent just seems to get better and better.

[eXtr4ktor]

The way it was in 1.1.3 was fine by me, someone pointed out, i rarely look at the general tab, unless i need to know from where i got the torrent. Showing the real peer and seeds info seems to be the best for everyone. Either way, i love uTorrent

[chaosblade]

I also second segosa's suggestion, nice to know .5 will have something similar, though i dont mind it that badly (but i do prefer the old way, anyhow).

[segosa]

Loads of people are posting that the number is wrong in other threads

[sethg]

I think what is at issue here is what is the best estimate of the number of seeders, sharing peers and leaches in the swarm at any given moment. These numbers are partly a proxy for data availability within the swarm. We need a good estimate of those numbers in order to make sensible decisions on seeding priority, download and upload bandwidth allocation. No matter how clever our algorithms for making those decisions, to the extent that the data upon which we base those decisions is wrong, the quality of the decisions will suffer.

While the tracker is the only entity that is in contact with all clients, individual clients only report back occassionally (i.e. at 30 minute intervals when things get going), so the tracker's data is not very accurate. This is particularly so when the swarm is small and worse if the situation is volatile. This is coincidentally when it is most important to make correct decisions. Small swarms are more fragile than larger ones. It is also the most likely time that recent local data may be more accurate than that from the tracker. I would therefore argue that it is most important to accurately estimate the number of clients of each class when the swarm is small. This either means that the tracker must ask clients in small, volatile swarms to report back more frequently, or clients should make some use of recent local data to improve the quality of the data from the tracker.

The list of other clients with whom any individual client has been in recent contact is limited. However, if the number of those clients of a given class is larger than the number from the tracker, then the local data is probably more correct than the tracker. This is only true if the local data is newer than that in the tracker. It will also only tend to occur when the swarm is very small, very volatile or both. Local data will very rarely be more accurate than the tracker data for large, stable swarms.

I don't know if the BitTorrent protocol has anything to say about how often clients must report back to the tracker. Given the fact that the average interval for a client reporting back to a tracker is X, and a large number of clients report back asynchronously, the expected age of the client data at the tracker is X/2. If we can know X, one algorithm might be to consider local data that is newer than that at the tracker and to use the greater of the two numbers. When I say newer, that raises the question of by what measure: average, maximum, median, rms, something else?

I propose that a conservative and simple choice would be to only consider local data records that are newer than X/2. I am assuming that the distribution of the age of local client data is unknown, but it is likely not uniform. Regardless of the distribution, the expected age of local data would be less than X/2. This has the effect of only overriding the tracker data if we have more recent data that suggests the tracker number is too small.

While the particular choice of algorithm for what is more recent is abitrary, at least the concept may be defensible. Hopefully, this would lead to better decisions regarding our behavior in small swarms. The better the decisions we make, the higher the effective multiplier of any data that we upload or the more stable the swarm will be.

This makes several assumptions, which may or may not be valid:

1) We can determine the average interval that clients report back to the tracker.

2) All clients of a particular tracker have the same average reporting interval, or at least the distribution is known.

[sethg]

I've observed some behavior that may be a possible bug in the way the number of seeders is used. When a download completes and you go into seeding mode, the number of seeders reported in the general tab goes to 0 connected (0 in swarm). At the same time, the number of peers in the swarm in the general tab immediately goes up by the number of seeders that were there just before the download finished. IOW, it appears that when in seeding mode, uTorrent is somehow interpreting seeders as peers. This causes the number of seeders in a given swarm to always be less than the default value of five in the seeding priority tab and the torrent stays in prioritized seeding mode regardless of how much data you uploaded. Manually refreshing the tracker does not fix this.

Comments?

[sethg]

Sharing ratio of "inf" is treated as less than 150% for the purpose of prioritized seeding.

One other item is a possible improvement to the UI, if you agree. While the local list of seeds/peers is kept in memory for 30 minutes, in case they reappear, the byte counts downloaded and uploaded to them is not retained. Thus, when a peer briefly disconnects then reconnects, their byte counts start again from zero. This distorts the overall picture later in the download, as you may have been fed most of the file by one generous host, but you don't know that.

[Snoopy1966]

Yes I too would like to see the seed/peer option on the main screen. There is no way to look at a quick glance of what needs a seeder without going to the general tab. To much work just to check torrents. How does the Super-seed work as stated on the improvements. I have made a few new torrents with the new version and I have not seen it go into super-seed. Is there a way to enable it? I do not see it. Keep up the good work on this bit torrent client.

One other question, I downloaded one torrent and it was fine but I noticed the icon switching from red to blue when downloading and red to green when seeding.

Thanks

[sethg]

When a torrent is stopped manually, the display in the list view of the numbers of seeders and peers in the swarm does not appear to age out after 30 minutes. When the torrent is manually restarted hours later, even after successfully communicating with the tracker, it looks like the old values still remain in the list view. I don't know if uTorrent still tries to use that old data and bothers clients who are no longer part of the swarm, which would be impolite. I think the list of recently connected clients should age out using the same rules whether or not the torrent is active. Similarly, when the torrent is manually stopped, it makes sense to add to the list clients who initiate a connection for that torrent.

[coqauvin]

After downloading a file from a tracker I saw 6 seeders and 3 peers. Which was completely wrong. On the tracker there was 9 seeders and no peers(leechers) I can attest to the tracker's valid count. But if this an indication that sits for 30 minutes... I will be lost to interpret what uTorrent is showing in the seed and peers columns.