3.4.x stable

[Ryrynz]

At the moment it seems they are collecting all possible bugs and make stable builds from that.

Talkingprawn what the actual f are the guys there doing? These aren't proper stable builds you're putting out.

Does Bittorrent Inc have any idea what a stable build actually is? Because you're missing mark in the most poignant way possible.

[hermanm]

on build 40329. still having issues with torrents not starting, or stopping after some time. if i stop the torrent and restart it... the download speeds increase again.

[Seyss]

wtf is this running on my pc? utorrentie.exe

[DreadWingKnight]

Separate process for ads to help with troubleshooting ad crashes.

[Seyss]

thanks. can you please see why the tab buttons are still not showing up correctly?

[xriothhh]

Stable build 40466 "released"

 

US IPs have a 1-5% chance of downloading it - from the OpenCandy bundled variant CDNs

UK IPs 15-22% - from the non-bundled variant CDNs

 

Remainder chance will download either variant build 40298

 

 

Haven't tested other VPNs yet to assess a percentage via russian roullette downloading.

 

It was propagated to some of their CDNs yesterday.

 

After 2-3 weeks that will be closer to 90% for US IPs - as per usual for Bittorrent Inc's odd CDN system.

[talkingprawn]

Thank you xriothhh -- This isn't quite accurate though, 40466 was released as a beta for a short time, it was never a stable and is not currently being served anymore.  40298 is still the current stable though we are working on a new release to fix the handful of bugs reported in it, e.g. the tabs bug and status bar bug.  Sorry for the delay on that everyone!

 

xriothhh, please let us know if you experienced something different from the above with 40466.

 

thanks!

 

Stable build 40466 "released"

 

US IPs have a 1-5% chance of downloading it - from the OpenCandy bundled variant CDNs

UK IPs 15-22% - from the non-bundled variant CDNs

 

Remainder chance will download either variant build 40298

 

 

Haven't tested other VPNs yet to assess a percentage via russian roullette downloading.

 

It was propagated to some of their CDNs yesterday.

 

After 2-3 weeks that will be closer to 90% for US IPs - as per usual for Bittorrent Inc's odd CDN system.

[xriothhh]

It was available in the stable download URL for a time

 

 

Here is a copy of the binary: ********************

 

All of the metadata including user-agent and peer ID reports as a stable version.

EDIT by schnurlos: Seems like the exe you linked is infected. I sent you an email, please answer.

[HedgehogInTheCPP]

Good day to all!

Please give it to developers!

1) Remove the asynchronous data loading of program startup, this is slow, very crooked and creates a heavy load on the system.
1.1) Test Case for best performance and user experience: Start the client with the stopped torrents: starting and loading a list of torrents lasts about 5 seconds on my configuration (~ 1200 torrents and powerful server hardware produced in 2011 year). Click Start in the context menu for all the torrents, the client hangs by about 5 seconds, after which the client can use. Total 10 seconds a client can use.
1.2) Test Case for current startup mechanism: Run the client with a running torrents: starting and loading a list of torrents lasts about 40 seconds, the client in this case most of the time hanging out and use it impossible. After loading the list of client hangs for about 15 seconds, after which the client can use. Total after 55 seconds, the client can use.

2) I have some resolution of the device on which the program is 2/3 of the time just hanging out, and the load on the system tends to 0, and according to the Task Manager (Process Hacker), most threads are blocking and waiting for something, that is, the bulk of the time the client spends in Live Locks !!!

Please contact me, I am an experienced developer of the C/C++ with more than 10 years of experience. With joy and free! help carry out the necessary tests. Even if you are not ready to create at similar conditions, you can safely give me a version that collects trace and I, happily, archive and send you the details!

[HedgehogInTheCPP]

I tried 40466, interface responsiveness increased slightly compared to the previous 40298, but there was a noticeable eye redraw the GUI. In addition, when you start the active tab to the torrent always resets to the "Files".

[rafi]

Starting 1200 torrents is a bit insane use-case... Don't you think? Set the queue  to 20 active and re-test...

[HedgehogInTheCPP]

Starting 1200 torrents is a bit insane use-case... Don't you think? Set the queue  to 20 active and re-test...

Apparently I was wrong to explain the situation! Setting active torrents there set to 25. By running torrents meaning the situation when they are in a state of "Queued"! Under the full stop is meant to stop their state "Stopped".

 

P.S. If you activate the transmission (forced start) 1200 torrents at the start of the client will hang very long time ... to tens of minutes for sure because I have never once not wait

[boomman]

After I've upgraded from 38xxx build to latest "stable" 40xxx build I could no longer download a torrent. The tracker would update, the peer list would download, but torrent won't actually get downloaded, hovering at 2kbps down, as if not a single assorted version of client in a swarm (where I noticed a couple of 3.4.3 versions too) would give me a single piece. I waited half an hour to see if it would stop being bad, but it didn't change a thing, I couldn't download anything.

So, I've upgraded (from 3rd party website) to 38397 build and instantly got back my healthy 6 MBps.

Won't try updating anymore for sure.

[DreadWingKnight]

Fix your broken internet security software. Don't blame us for that.

[eddlang]

Fix your broken internet security software. Don't blame us for that.

To be honest, I also see a similar situation with build 40298.

 

Sometimes, when I add a torrent to utorrent, it fails to connect to seeds/peers properly and (maybe it does connect, but still) the speed doesn't go above a few KB/s.

 

The workaround is to stop the torrent, completely close utorrent and then launch it again. Now it'll download properly at full speed.

[rafi]

To be honest, I also see a similar situation with build 40298.

 

Sometimes, when I add a torrent to utorrent, it fails to connect to seeds/peers properly and the speed doesn't go above a few KB/s.

 

The workaround is to stop the torrent, completely close utorrent and then launch it again. Now it'll download properly at full speed.

I have seen something  similar with the speed as well. In my "case", the client was simply throttling the speed to 0 since it has filled up the RAM cache and was not writing to the disk at all. After about 1-2 minutes it has started to write to disk, and everything was fine again.

[icebox]

So I asked this question before, but never got a good answer.  Since late december builds, I've been having the problem that after a day or two, sometimes, but not often longer, the program stops making connections either up or down.  This is not lack of traffic, because I can't make connections to download either when this happens, with downloads, the program will communicate with the tracker, get the peer list, but not go any farther.  this has happened with every build since, and currently I'm using 3.4.3 build 40298.  Is there any explanation or solution for this?  No, there's not abnormal disc activity when this happens, and no corked jobs in the queue either.  It's just inexplicable to me.  I'm running utorrent 2.2.1 concurrently, and never see this behavior with that client.

 

If I can't solve this my next question is, is there any way to easily merge two different resume.dats so if I want to start using 2.2.1 exclusively again (and I really don't) I don't have to manually add a ton of torrents.

[rafi]

Do you have a limit set for either DL,  UL or both? What is your pref.->adv.->bt.transp_disposition? Is it the same  with 40580 beta (not that I expect it'd behave differently...) ?

[HedgehogInTheCPP]

Friends, colleagues !!! I finally found a version in which there was a huge problem with live Locks! Fortunately I have a machine on which the problem is clearly seen: 3/4 the time the program hangs, and sometimes wake up from a coma and a couple of tens of seconds works! So, the latest version 3.4.2.35702 workable without this problem, but starting with the next (3.4.2. 36044) All versions, including 3.4.3.40298 and 3.4.3.40466 affected. Unfortunately, nothing changes in the log:
 

-- 2014-11-14: Version 3.4.2 (build 36044) Stable- no changelog-- 2014-11-11: Version 3.4.2 (build 35702) Stable- Fix RSS refresh and startup problems- Fixed reversion to standard after Plus expires

Please check that you have changed between revisions. In this small ranges you broke the core of the program is thorough!

[rafi]

Excuse my ignorance, but what are "live locks" ? Cause I don't think I see any in 40580....

[HedgehogInTheCPP]

Excuse my ignorance, but what are "live locks" ? Cause I don't think I see any in 40580....

http://stackoverflow.com/questions/6155951/difference-between-deadlock-and-livelock

 

 

 

ie the application does not hang forever, but most of the time in the locks and unresponsive (a few tens of seconds at a time). It is clearly seen that happen feverishly context switching, and to a couple of the latest version, a small I / O observed. However, no network or disk activity. Probably one of the threads that is waiting, and as a result the entire application is waiting for this thread as he took possession of a monopoly by some global application resource, well, or a similar situation. Perhaps because of some evident timeout operation, which is carried out under the oversight of the lock or something like that. Generally, after version 3.2 in connection with the parallelization of many processes in the application it was very bad performance under load.

Spend profiling using Intel V-tune Amplifire, with 1000 torrents in the client and look for the code on the most ... Hachiko place . Or just spend a stress test is not on the top-end hardware, but at what a tablet with an atom. Although the atom, in my Core 2 Q9550 c 8 GB of RAM this whole orgy there, but on the server e3-1240 (actually i7) with 32 GB of RAM, this problem is quite unnoticeable. It's funny that in the calculator-transmission routers flies. Optimize, please have this horror.

[schnurlos]

@IRainman: I can understand what you mean.

 

I have to different possibilities to connect to the internet (both well forwarded and properly downloading/seeding):

• 1st a cable bound slower 1MBit down/256kBit up connection and
• 2nd a LTE 30MBit/3Mbit wifi connection.

 

With no.1 I recognize same behaviour when switching peer resolve on and of. Rest of uTorrent doesn' lag - just the program hangs and is not responsible for approx. 5-10 secs.

[rafi]

I don't see any such behavior using the latest beta

 

@IRainman: I can understand what you mean.

 

I have to different possibilities to connect to the internet (both well forwarded and properly downloading/seeding):

• 1st a cable bound slower 1MBit down/256kBit up connection and
• 2nd a LTE 30MBit/3Mbit wifi connection.

 

With no.1 I recognize same behaviour when switching peer resolve on and of. Rest of uTorrent doesn' lag - just the program hangs and is not responsible for approx. 5-10 secs.

[icebox]

Do you have a limit set for either DL,  UL or both? What is your pref.->adv.->bt.transp_disposition? Is it the same  with 40580 beta (not that I expect it'd behave differently...) ?

No limits.   bt.transp_disposition is the default 31.  I don't use the beta as the main sites I'm on don't allow beta builds.

[rafi]

Having no UL limit is not the best thing. You can try my settings (@sig) see if it makes any diff..