Established Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Fadeout

  • Rank
  1. Same problems as previous version, upload overhead goes above the limit and the numbers in the bottom bar still do not count overhead.
  2. I don't like much this version. Even with overhead set to true (as it should be) the numbers at the bottom do not show real traffic anymore. And the upload overhead in the graph STILL overshoots the limit by a good margin with no intention of sticking to it. And my external monitor even shows numbers higher than utorrent + overhead. Countries flags are gone for me as well. It's like you want to only play mind games with us. Overhead has to stay in the picture.
  3. This is to prove I'm not lying. Done with the udp test build in the last page: [2010-01-08 02:53:21] No sending uTP connections. [2010-01-08 02:53:24] uTP recv rate: 182738 setting TCP recv rate to: 4610296 (min_receive_delay: 1ms diff: 1743 tcp/utp: 96/20) [2010-01-08 02:53:24] No sending uTP connections. [2010-01-08 02:53:25] uTP recv rate: 36712 setting TCP recv rate to: 4612039 (min_receive_delay: 1ms diff: 1743 tcp/utp: 96/20) [2010-01-08 02:53:25] No sending uTP connections. [2010-01-08 02:53:26] uTP recv rate: 95599 setting TCP recv rate to: 4613782 (min_receive_delay: 1ms diff: 1743 tcp/utp: 97/20) [2010-01-08 02:53:26] No sending uTP connections. [2010-01-08 02:53:27] uTP recv rate: 93628 setting TCP recv rate to: 4615525 (min_receive_delay: 1ms diff: 1743 tcp/utp: 96/20) [2010-01-08 02:53:27] No sending uTP connections. [2010-01-08 02:53:28] uTP recv rate: 169761 setting TCP recv rate to: 4617268 (min_receive_delay: 1ms diff: 1743 tcp/utp: 98/20) [2010-01-08 02:53:28] No sending uTP connections. [2010-01-08 02:53:29] uTP recv rate: 130318 setting TCP recv rate to: 4619011 (min_receive_delay: 1ms diff: 1743 tcp/utp: 99/20) [2010-01-08 02:53:29] No sending uTP connections. [2010-01-08 02:53:30] uTP recv rate: 71825 setting TCP recv rate to: 4620740 (min_receive_delay: 3ms diff: 1729 tcp/utp: 99/20) [2010-01-08 02:53:30] No sending uTP connections. [2010-01-08 02:53:31] uTP recv rate: 166866 setting TCP recv rate to: 4622476 (min_receive_delay: 2ms diff: 1736 tcp/utp: 99/20) [2010-01-08 02:53:31] No sending uTP connections. [2010-01-08 02:53:32] uTP recv rate: 121539 setting TCP recv rate to: 4624205 (min_receive_delay: 3ms diff: 1729 tcp/utp: 99/20) [2010-01-08 02:53:32] No sending uTP connections. [2010-01-08 02:53:33] uTP recv rate: 151166 setting TCP recv rate to: 4625934 (min_receive_delay: 3ms diff: 1729 tcp/utp: 99/20) [2010-01-08 02:53:33] No sending uTP connections. [2010-01-08 02:53:34] uTP recv rate: 93895 setting TCP recv rate to: 4627670 (min_receive_delay: 2ms diff: 1736 tcp/utp: 99/20) [2010-01-08 02:53:34] No sending uTP connections. [2010-01-08 02:53:35] uTP recv rate: 168245 setting TCP recv rate to: 4629406 (min_receive_delay: 2ms diff: 1736 tcp/utp: 99/20) [2010-01-08 02:53:35] No sending uTP connections. [2010-01-08 02:53:36] uTP recv rate: 178124 setting TCP recv rate to: 4631142 (min_receive_delay: 2ms diff: 1736 tcp/utp: 99/19) [2010-01-08 02:53:36] No sending uTP connections. [2010-01-08 02:53:37] uTP recv rate: 97705 setting TCP recv rate to: 4632878 (min_receive_delay: 2ms diff: 1736 tcp/utp: 97/19) [2010-01-08 02:53:37] No sending uTP connections. [2010-01-08 02:53:38] uTP recv rate: 171582 setting TCP recv rate to: 4634607 (min_receive_delay: 3ms diff: 1729 tcp/utp: 97/19)
  4. I used to have it set at 40. But with this version I have to set it at 15 to have full speed. I saw it go up to 40 or 50 with upload limit set to 15. So it's 15 real upload and 20/30 overhead (and if I set upload to where it was it chokes download speed and internet whole). This maybe because I have a connection that can reach up to 700 in download, so a lot of overhead for upload. I'm starting to understand from Firon that you DO NOT WANT to include overhead in the limit, but this just won't work here since I have to set my upload much lower at all times. Either you fix this or I may as well go back to an old version and stick with it instead of waiting for a fix that won't arrive.
  5. If the big overhead is not a bug then my problem with download speeds is entirely because I can't apply upload limits to overhead too. So getting that part fixed would entirely solve the problem for me. Even if these changes above help to keep overhead under control the limits still have to be fixed. "Huge" overhead means that I can see my upload grow to almost 150% above the upload limit I set.
  6. I also verified that the HUGE upload overhead is directly related to download speed (so the faster I download the bigger thee upload overhead I get). Is this normal? Shouldn't download overhead be counted in download instead of going into upload overhead?
  7. I'm getting very bad downloading speeds with 2.0, so I started to experiment. I use Cfosspeed that works like traffic shaper and until now worked perfectly with utorrent, maximizing download speed the best it could be. It seems it doesn't work too well with UDP. But the real problem is another. It seems that my download speed problem is entirely due to UDP upload taking all the bandwidth. In the graph I have the upload total (bright red) at least 150% higher than the limit I set. I guess that upload limits only apply to actual transfer and not to overhead or this wouldn't happen. Well, is UDP upload overhead meant to take all that bandwidth? I get downloading speeds in 2.0 similar to 1.8 only if I set my upload limit at less than HALF of where it was. Beside the problem of UDP overhead being so huge I'd also like an option to set the upload limit apply to overhead as well. This would help my downloading problem, but it still wouldn't explain why the overhead is using all my bandwidth alone.
  8. There is something wrong with this build. The client reports CRAZY speeds, capping completely the connection I have (I see an average above 750k sometimes, and that's a 7M adsl line). The problem is that even the upload is constant and capped at 40, while I know that I wouldn't be able to keep 40kb in upload if I maximize my download like that. In fact my netspeed monitor shows that the download is indeed 750k, but the upload goes between 18k and 20k, exactly like it should realistically be. So utorrent is at least reporting upload speed incorrectly.
  9. The new build seems to work now with default settings.
  10. For me 1.8.3 with bt.tansp_disposition set to 5 works absolutely great. 1.8.3 with default setting instead has jerky upload speeds. It doesn't die, but it's not the smooth line I see with the standard protocols. I also always use cFosSpeed as it works amazingly well and prioritizes packets so that upload doesn't choke download. It regulates speed on its own, if the download speed goes up, the upload speed adjusts to grant maximum performance.
  11. Confirming HUGE memories issues and consequent freezing even on XP.
  12. How auto-update is supposed to work? I have it enabled but it doesn't seem to do much...
  13. Let me explain better. The case of prioritizing the last part of a file would be used for previewing video files. Now this feature is being refused because it may harm the distribution of the file. In this specific case it would mean that there is a very small number of peers/seeds. So let's say 10 or less. If there would be more than 10 then a preview option wouldn't do any noticeable harm to the distribution. Now let's see what are the consequences in that case. Well the consequence is that the "preview" parts would be distributed first. If the torrent has already a so low number of sources then it's at risk whether the preview option exists or not, the risk would be just slightly higher. With the difference that with that preview option you at least guarantee that a partially downloaded file would be at least playable, while in the other case you would finish with just a broken file that you cannot use in any way. I mean, let's say that this hypothetical torrent has a so small number of sources AND that everyone is using that preview option. The worst case is that they could at least preview the file if the preview option existed, while with the current client they get a slightly better chance of completing the file, but at the risk of not being even able to preview it in the case it cannot be completed. So the bottom line is that a preview option would be harmful only in the case the torrent ALREADY risks to be incomplete. And in that case it would at least allow to preview the file. I think the compromise is worth the very minimal impact it could have in very rare cases. I'm just saying that it's being proven (in practice) that the option isn't having any noticeable negative effect. I'm not discussing BitComet, just using it as an example that the apocalyptic scenarios evoked in the case this option existed are largely unfounded. I could say the same for eMule. It also allows to preview files and I don't see noticeable negative consequences because that option exists. It's a minor compromise that I believe it's worth the price.
  14. I believe that the scope of this change is more about the "presentation" than anything else. Just as an example: BitComet is very popular in the east and it already allows to prioritize preview pieces through a player that directly ask for the pieces needed. What I mean is that I don't see any relevant negative consequence. World isn't falling apart because of that feature. Torrents still work and that feature seems to have a very minimal impact overall. If a full control is too harmful it could be at least implemented a partial control that lets you download the part necessary to preview a file. In every case what you need is enough of the file at the end. So you could use an option that gets about 8% of the file at the end and it would be enough to do the trick. In the worst case you may finish with an incomplete file, but at least you could load it in a player and see at least those chunks you have downloaded. Hey, that's better than be left with a partially downloaded file that you cannot play at all
  15. In fact it can be a custom option turned off by default. Its purpose is, in fact, limited. It wouldn't be hard to let users know that the option should be used with discretion and for what reason. Nope, it's undeniable that there are good and legitimate reasons to have this option. It's not to deliberately "sabotage" a torrent. My idea is not to completely override the standard distribution. Just to select an area of a file and have it prioritized. This means that the standard distribution would still work, but instead of working on the whole file, it could work on just the first 100Mb, or whatever I select as the area to prioritize. There ARE reasons and uses for such a feature. I may want to download just one part of a larger movie, or be able to preview a file, so requiring more pieces toward the end. I KNOW that previews can be done externally, but it's undeniable that many files don't have it and so the user may feel the need for such an option. It's simple: if you don't think the option is useful then you don't use it, and make sure that it's disabled by default so that the users won't mess with it without knowing how it works.