AdamK

Here is what the uTorrent team would like to do in the near future: Add the ability to make some problem reports and viewing the changelog into the client itself. We don't have the system we need to do this yet.

Here you go: http://forum.utorrent.com/viewtopic.php?pid=766512#p766512

Can you describe your reproduction steps? Are you able to reproduce this with default settings?

-- 2013-12-24: Version 3.4 (build 30444) RC3 - Fix: Installer issue when going from 3.3.1 or before to 3.3.2 or later: infinite mutex wait - Performance Fix: Main Torrent listview should update only when needed - Fix: Installation issue: Run at startup not set - Fix: The information of deselected torrent remained in the tabs area - Change: Remove [x] next to Ads - Fix: restore crash count information - Change: Write more aggressively when coalesced pieces exist in cache - Possible fix for netprofm.dll related crash, appearing after MS patch to IE 10

-- 2013-12-18: Version 3.4 (build 30429) RC2 - Fix: Incorrect text color (black) when highlighted (dark blue) on XP - Change: point initial page for fresh install to bundles.utorrent.com (nee /current/index.html) - Fix: Bug affecting Plus customers - Feature: Add BitTorrent Labs icon to the status bar - Fix: Bug in categorizing torrents may lead to some missing in UI Download the new version now!

Does this magnet link work? magnet:?xt=urn:btih:E3811B9539CACFF680E418124272177C47477157&dn=ubuntu-13.10-desktop-amd64.iso&tr=http%3a%2f%2ftorrent.ubuntu.com%3a6969%2fannounce&tr=http%3a%2f%2fipv6.torrent.ubuntu.com%3a6969%2fannounce

Thanks - I just accepted a patch for that a few hours ago. That fix will be out today.

On a RC???? No' date=' not on an RC. The beta track works that way currently, but there is only one RC at a time. [url']http://download-lb.utorrent.com/endpoint/utorrent/os/windows/track/beta http://download-lb.utorrent.com/endpoint/utorrent/os/windows/track/rc Still present in build 30379 Last working 30304 but not on 30300. Still present in build 30428' date=' fix it please.[/quote'] Thanks for giving the version numbers, that will help a lot.

Yep, we're working on the high-CPU issue, and we have it reproduced here. Once we isolate the cause, we can assess how complex the fix will be. The over-eager disc-overload message is probably going to be a bit more tricky, but we'll see.

That is hilarious! Don't worry, we are almost finished coming up with a plan for releasing features, that I think we'll all be happy with. Once I get everyone at the office to review it, I'll post it here for all the testers, as well. (I'm hoping to get started in January). I think it will take us about a month to do, once we start. AdamK

Hi everyone, thanks for pointing this out - we tracked it down to overflow in a 16-bit counter used to determine when to send performance/usage data (e.g. How often do users use the RSS feature vs. the Add Torrent feature)

Changelog: Note that you will occasionally see other versions being served from the download link. These are builds to test special bug-fixes or features that are not yet battle-tested -- 2013-12-16: Version 3.4 (build 30428) RC1 - Fix: .torrent association problem during install on Windows 8 and later - Feature: Add BitTorrent Labs icon to the status bar - Feature: Add Help menu items for bundle and BitTorrent Labs - Fix: Toolbar buttons are not activated after adding torrents - Change: Default button in delete torrent dialog is now [OK] - Fix: Firewall issue if running client from downloaded folder - Change: Implement bundle badging - Change: Implement bundle unlock toolbar - Change: Implement bundle unlock right click menu - Change: Implement bundle history tab - Fix: MON-3: Search icons not showing when client first starts - Change: Highlight the last newly added torrent - Fix: Toolbar buttons are not activated after torrents are selected - Feature: ADS-138: Change logging in settings to remove OpenX - Feature: ADS-176: Keyboard shortcut to refresh ads now - Feature: ADS-33: Overlay image when "i" is moused over - Feature: ADS-35: Custom PDD

Thanks for your feedback. I think giving a full changelog for the test versions as well is a good idea. Two main problems we'd like to solve: * Don't expose more users than necessary to bad versions * get new revisions in front of users as quickly as possible (These versions may be developed in parallel)

Hi - Thanks for your dumps for 30345. That issue seems to be fixed in the next version. Could you give that a try? http://tinyurl.com/orarlep

Thank you for your helpful commentary.

Ok, so it sounds like you would prefer a process like this: Introduce features 1-by-1 in the alpha channel. If they check out, then add them to the beta channel. Don't expose beta testers to parallel lines of development. BTW, what we won't move back to is: pile up a ton of features/fixes/changes in one release (e.g. "3.5"), move that to beta, pile in more changes, move that to stable, pile in even more ...

Hi Grey Rat, That is a great topic for the bt dev list: http://groups.google.com/a/bittorrent.com/group/bt-developers/ If you join that list and ask the same question, I will put you in contact with the person you need. Thanks.

It was "ideal" as it was before - "linear" with direct links... Ok, so is that a vote for a separate Forum Thread per feature, or for only exposing features to the testers one at a time?

Yes, the system we are using right now is "broken" - not in a technical sense, but in a social sense. It is broken for what we are doing right now, which is beta testing with a wide variety of expert users. Users are used to a beta tracks that follow a linear change path. e.g. Even with the huge number of changes that Chrome pushes, they only have 4 tracks Of course, their change tracking and regression testing is way more complex than ours. There are two main types of testing we are doing * Crash rate spot checks - make sure a branch's crash rate is still low * New feature development I think we have to do the spot checks without tester interaction - no one is going to download and test a build whose changelog is "feature in development, test stability" I agree that the new feature branches should be exposed directly to testers. Here are some things we are considering (but not committing to): ** Opening a separate Forum Thread for each major feature * Upsides: testers know exactly what they are getting, and have a place to discuss only that feature * May be very short-lived * Downsides: Will we get enough testers on that feature? ** Incorporating the changelog notification into uTorrent itself * I like this one a lot, because the changelog is right there - no mismatches ** Incorporating feedback into uTorrent itself * This could save us all tons of time, because if the user agrees, we could send back the version number, and other state that will help find a bug. What you are not seeing behind the scenes is that: * We are releasing a lot more often - about 7 times as often as before, and still increasing. * We are testing things faster, and more independently of each other * uTorrent's crash rate has gone down and *stayed low* I want to be able to make changes to uTorrent without wasting everyone's time with stability regressions In short, the new system sucks for betas, but is awesome for: - Keeping uTorrent stable - Working on more than one thing at a time, and only merging stable features So all we have to do now is fix it for betas. Help me by telling me your ideal system, and we'll see what we can do.

Yes, that's the Bundles test branch. I will have devs pushing test branches add them to the Changelog.

Hi - please upload your dumps, and we will take a look. Thank you.

-- 2013-12-03: Version 3.4 (build 30378) - Fix: Incorrectly applied rate limit state affected utp - Fix: utp seeding - Fix: gui.show_status_icon_in_dl_list was not showing status icons - Fix: After deleting a set of torrents, others would become selected - Change: Disable "Stream" button in torrent list. It will re-appear after extensive testing

What happened to this reasonable change?... http://thumbnails107.imagebam.com/29001/c099be290001926.jpg Nice try' date=' Rafi. This is the Play (media) button: [url']http://imgur.com/pMWi6Zu You are talking about the download / start torrent button, which we also intend to fix.

-- 2013-11-20: Version 3.4 (build 30345) - Tooltip for torrent error state: Display entire error text - Feature: Simple Custom Post Download Dialog (PDD) for autoexecuted torrents from ads - Fix: Detect all compatibility modes, not just Vista - Change: Play button graphic changed - Fix: Remote access feature re-enabled

What happened to this reasonable change?... http://thumbnails107.imagebam.com/29001/c099be290001926.jpg It will be in today's build - the changelog was out-of-order.