Archived

This topic is now archived and is closed to further replies.

Firon

µTorrent 3.2 stable (27568)

Recommended Posts

Fix: Magnets would be added in stopped state in 3.2.1 but not in 3.2 stable.

Why?

3.2.1 > 3.2, and maybe they've forgotten to back-port the bug fix? ... :)

Share this post


Link to post
Share on other sites

Can't find options for Windows caching. I would like to use Windows cache for reading, cause have 12 GB of RAM and only 1,3 GB is used (+1,52 GB if we set 1500 MB for uT cache).

It's a bug for the developers have removed this feature?

Share this post


Link to post
Share on other sites

Those where canceled, when they've started using file IO in buffered mode (always using Win cache).

Share this post


Link to post
Share on other sites

rafi

Thx, but what can I do now? Which option I can change to make uT use more memory?

I can't use 1500 MB cache - during upload and download uT can hang. 1350 Mb is ok for me, thats all I can do about cache memory in this version of uT.

Also I've noticed that I get best results when diskio.cache_stripe is set to 512 or even 1024 (there many "dummy" reads I guess but some of them hits the target). And diskio.coalesce_write_size with diskio.max_write_queue I use much more than default.

I've got 80/80 mbit and two slooooow HDDs - WD Green (with AAM on 255 (so they got slow seek)), and up to 100 torrents (active up to 30-40 at the same time).

So the default settins is definitely not for me :/ And only with that settings I can see high speeds.

Share this post


Link to post
Share on other sites
Thx, but what can I do now? Which option I can change to make uT use more memory?

You are asking me? ... :) My answer is in me settings/sig...

Eventually, what counts is not how large you can set your cache to (I think it is 1800M now) , but how efficient uTorrent is handling file IO. They suppose to try and improve some aspects in the next 3.2.1 release. Till then, you can try the tips here:

http://forum.utorrent.com/viewtopic.php?pid=671702#p671702

Cache is for helping with temporary load conditions, not sustained continuous ones...

Share this post


Link to post
Share on other sites

Just hope development team will be back from vocation with new power to fixing bugs and finally proper magnets handling and support :P

Because now every time I use magnets with uTorrent I feel like this

utwsw.png

Share this post


Link to post
Share on other sites
to fixing bugs and finally proper magnets handling and support :P

meh... it is mostly proper right now... maybe one of two "glitches"... like "auto-stopping" the downloading torrent after the meta-data arrives... ;)

Share this post


Link to post
Share on other sites

Tried 3.2 after I reverted to 2.2.1 and I'm sad to see that I have the same issue that I had since version 3.1 stable hit. Peers won't connect between tracker updates => I can't have a decent ratio. 2.2.1 and 3.0 worked like a charm and 3.1 until 3.2 are acting up. Tried 1000000000 settings and even trid with the default ones. The same. If the tracker does not update, there's no peer connecting to me. And yes, it's allowed in the firewall and in the antivirus.

Share this post


Link to post
Share on other sites
Peers won't connect between tracker updates =

How can you tell? did you enable logging for incoming connections? what did you see on help->show-stats if you delete all trackers and enable DHT, having peers in your list?

Share this post


Link to post
Share on other sites

Deathstalker:

The article does not say what the specific proposal is. Is it to remove the cability of adding trackers to a torrent list? What about when creating a torrent? Is it to check the list to insure that the client does not allow the adding of an http: tracker entry for their specific site? What about programs outside the torrent client that allow the user to edit torrent? Is it to provide better handling of errors from the tracker? If I get errors concerning a tracker I remove it (depending on the error).

"overloaded with bogus announcements". I fail to see how the announcements are "bogus" - in a general sense. I can see the point that a request for peers for a torrent that is not in their database can be considered bogus. But that may not have been the intent of the torrent creator. What is the error ratio of valid to bogus requests?

BitTorrent may feel it is not their responsibilty to clean up torrents that are loaded by replacing a specific url with another. It surely would slow the loading of a torrent into a client - and as more trackers change their url - slower again.

I do know a site several months ago that posted they were reducing the number of tracker url(s) to a single url. I did not see them recommend that clients be modified to automatically make that change.

Share this post


Link to post
Share on other sites
Deathstalker:

The article does not say what the specific proposal is.

The proposal was to consider implementing this BEP into the protocol:

http://forum.bittorrent.org/viewtopic.php?id=987

That is, to make it so that the tracker can inform the client about it's capabilities, thus avoiding unwanted communication between the two. At least, that is what I've figured.

PS:

Though, this can be a good idea, it does not concern BT alone, but *all* the clients and *all* the tracker sites.

Share this post


Link to post
Share on other sites

Here are just a few excerpts from that article....

http://torrentfreak.com/largest-bittorrent-trackers-go-offline-in-protest-120716/

"The issue has been brought to the attention of BitTorrent developers in the past, and two months ago Pirate Bay co-founder submitted an official proposal to the developer forum which is operated by uTorrent’s parent company BitTorrent Inc."

"The proposal is to add a functionality that allows website and tracker owners to inform BitTorrent clients whether connections are allowed or not."

The RIAA and MPAA are supporting OBT's and PBT's strike and hoping it lasts for a long time.

In the long run the RIAA and MPAA will benefit if developers and trackers don't see eye to eye.

Share this post


Link to post
Share on other sites

A lot of the problem stems from user stupidity regarding tracker lists.

They are of the delusion that adding a bunch of trackers will help their speeds.

Most of the lists that are out there add a multitude of trackers that:

1> Are down

2> Have been closed for over a year

3> Are duplicates/aliases of other trackers in the list

4> Communicate properly with other trackers in the list in such a way that they're actually one tracker (but are separated in the list like they aren't)

5> Have never been trackers

6> Don't track all torrents

Those lists are the root of the problem.

Share this post


Link to post
Share on other sites
Those lists are the root of the problem.

OK, yeah... but I thought that the proposed protocol change was kind of suggested solution to overcome a side-effect of that root-cause - using wrong url's (TCP/UDP).

Share this post


Link to post
Share on other sites

Maybe an implementation so that if it tries to connect to the non working tracker, etc., it won't keep trying to connect.

Just to relieve some resources.

Share this post


Link to post
Share on other sites
Just to relieve some resources.

What resources? A message of a few bytes every few minutes (and longer each time, per the protocol) ? If the tracker really does not work, it will not heart anyone. And a "reject" message is a good solution to stop using an invalid protocol. Just not a solution to the other 6 or so issues that were mentioned above :(

Share this post


Link to post
Share on other sites

Much like banning bad ip for sending bad data, do the same for trackers that are known dead. I did think connectible but then that could also be because they need to sign up to the tracker. So know dead ones are better. Store this in a hash value in a non dat file so cannot be deleted or other. Or better code those trackers into each new update of utorrent.

About DHT: I don't use dht unless I need to since it is a waste of bandwidth. And when do use am very happy when 1:1 and get rid of it again asap. I try not to use dht torrents at all.

Maybe I have this wrong, I excuse in advance if don't understand correctly:

DHT last used was I think 300+ connections always open and updating which is a waste of bandwidth and resources. Some sort of management to close those without seed, peers, leechers etc. A way for the dht tracker to inform the client for new dht connection when has a seed, peer, leecher etc if possible to do.

Share this post


Link to post
Share on other sites
know dead ones are better

Right, like an exclude/black list (ipfilter-like)... But, I guess processing power is a consideration too. I'm sure that even skipping double URLs/resolved- IPs inside trackers' lists can do some good too.

Share this post


Link to post
Share on other sites

Better error handling on the client side would be a big step forward on reduction of traffic. There are several cases where the retry timer shoulld not be set and the tracker disabled:

1. The tracker does not exist (http error 404?).

2. The tracker is not authorized for that specific torrent. (This may be not from a user adding a specific tracker to the list, but rather the tracker removing it torrent because of copyright issues.)

3. The tracker is private and the user is not authorized to use that tracker.

There are very old torrents out there that are still in demand, but (some) trackers inside the torrent no longer exist, or changed their port, changed or added a new protocol - such as udp.). I cannot see how uTorrent (or any client) can handle this unless there was a site that maintained a list of valid and current trackers (perhaps like DHT). Then the list of trackers within a torrent would not be necessary. Creators of a torrent would not be adding old tracker addresses, (Of course all you would need to do to stop sharing is to kill that site - that would only leave DHT.) Until there is a method to insure a valid list of trackers the user must be able to edit/correct the list.

So I would like to see better error handling on the client side. The elimination of duplicate tracker entries. But the user is still able to add trackers - there are to many old torrents out there that are still in demand that do not have valid trackers and are not DHT enabled.

Share this post


Link to post
Share on other sites
The elimination of duplicate tracker entries

This should be pretty simple to do. Better yet - first resolve all to IPs, and then do it... :).

I guess even now they actually filter communication from duplicate entries .

Share this post


Link to post
Share on other sites
Peers won't connect between tracker updates =

How can you tell? did you enable logging for incoming connections? what did you see on help->show-stats if you delete all trackers and enable DHT' date=' having peers in your list?[/quote']

I don't use public trackers => I don't need DHT. I saw it pretty simple. While the update interval was active, no peer was connecting to me. When I manually updated the tracker, the upload started with 10 mb/s. This occured 10 times in a row => it's not a coincidence. Anyway, staying to 2.2.1 until it will go off the internet. I think there's a setting that does this, but I don't have time to start and test every variation. This behavior occurs with the standard settings.

Share this post


Link to post
Share on other sites
A lot of the problem stems from user stupidity

DWK, a lot of car accidents stem from drivers stupidity. That's why car manufacturers install air-bags, seat belts, ABS's etc. And it's not always user stupidity because in many cases, the trackers are already in the torrents. Designers have to design stable products for everyone (including drivers, pedestrians, users, trackers) and I don't see a reason to blame the users.

Share this post


Link to post
Share on other sites
Ok Admins! WHY has there been no response?!

At least a *response* could provide a rational for not implementing the request.

Thank you!

http://torrentfreak.com/largest-bittorrent-trackers-go-offline-in-protest-120716/

Oddly enough, the real issue is mentioned in the article itself:

Both OBT and PBT abandoned TCP support to become UDP-only trackers last year. This was done to save resources. However, because many users keep adding HTTP addresses and since many old torrents also include these, both trackers are overloaded with bogus announces.

Bolded for emphasis.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.