Ultima

IE-only behavior... that never worked for adding by URL unless you tabbed to the OK button yourself. At any rate, it'll return for the next build (along with adding by URL also behaving that way now).

Oh, it's definitely not a full time thing. I'm just maintaining what I can, when I can. First post. Yep, version bump and return of the WIP tag, because I don't want to confuse users on v0.370, but I don't want to keep bumping the version number for each and every WIP build I push out with minimal changes. When I feel ready, I'll push the number up kinda appropriately/arbitrarily ;D This build has no major user-facing changes, but it actually involved a cleanup of the HTML/CSS. I can't tell for sure whether I've broken anything, but I did try to minimize the impact -- so I haven't noticed any real issues. No guarantees that I didn't break anything though, so feedback is most welcome.

The link works. If you were looking for 18834... well, that build doesn't exist. Must've been a typo that's since been corrected (see thread title and changelog).

Requested change made on my end. As for adding columns, it still works here in all browsers, so it doesn't seem likely that it's a bug with WebUI. Exit µTorrent, backup your settings.dat, then Esc in WebUI and try again.

First post as usual. This feature has been waiting for a release with backend support, and it seems like support was rolled into µTorrent v2.0.1 build 18723 (quicker than I had anticipated). People who have been asking for queue management support -- well here it finally is! Edit: I should like... bump the version number or something, since v0.370 has already been declared "stable". This version numbering scheme really sucks, and my constant reuse of numbers doesn't help make it any less confusing for users. Ugh. Next time, I guess.

I guess I'll include a 48x48 icon next time...

Indeed... Daylight saving time must've done a number on me, so that instead of jumping forward an hour, my brain jumped forward 3 days Fixed.

First post, as usual... That first fix should prevent the Detailed Info Pane from being hidden for users upgrading to v0.370. Still no guarantees that old settings will work perfectly (column handling is slightly altered from old versions). Users upgrading from versions older than v0.370 should probably still press Esc to reset all settings to ensure that corrupt settings don't cause bad behavior. Or at the very least, right-click the column headers for the listviews and hit Reset.

Something's broken on your end, not WebUI's. Adding by URL works in all browsers I've tested (Opera, Chrome, Firefox, Internet Explorer). My best guess? Demonoid is behaving stupidly (yes, I saw your previous post, but haven't had time to respond). Try a torrent from here.

They have access to Trac, so the tickets there are visible for them to see. I bug them to deal with some of the issues brought up there every now and then, but that's as well as I can do. Priorities can sometimes dictate that the developers deal with other more pressing matters in µTorrent.

@unity0110: No bug. @Bunta: That'd be up to the µTorrent devs. I maintain the WebUI frontend, not the backend.

No, using the main listening port works if you disable the alternative listening port. And in fact, it's recommended for the time being because there is a known freeze caused by use of the alternative listening port in µTorrent 2.0.

@Gico: Delete webui.zip and just re-visit WebUI. If you're accessing the correct URL, µTorrent should ask you to let it install webui.zip for you (and it'll install the latest version).

@ebe1961: Have you read the big, bold text at the top of the very first post in the thread?

Mirror... http://www.mediafire.com/download.php?wzyhe22m4ye Technically, the latest version is already hosted on utorrent.com, and µTorrent can already grab the file automatically if you delete webui.zip and try to access WebUI. But I don't know the exact location utorrent.com, and don't feel like figuring it out right now, so oh well.

Apparently, Google Sites limits sites that are generating heavy bandwidth load. I also received the same message as you earlier, but when trying just now, the link seems to be working again. Annoying, but at least they don't seem to be limiting bandwidth using some kind of static monthly limit or whatever (which would cause all links to stop working until the month rolls over). Edit: Mirrors... http://www.mediafire.com/?1u1dtf02u4nb15d (x64) http://www.mediafire.com/?jaizmmhd2aw (Unicode)

I have no problems using IE8 here, but either way, IE8 is just plain slow when it comes to anything JavaScript/DOM. Any other browser is faster than IE8. Heck, even the forthcoming IE9 is supposed to be much faster. My suspicion is that the slowness comes from the column handling changes made to the listviews to make it more language independent and more flexible to add new columns (should the need arise). I'll see if I can do anything about it anyway, but don't keep your hopes up, because honestly, I'm not even doing anything that complicated or heavy when it comes to managing the columns on initial load (I just swap a few DOM nodes around, resize, and toggling visibility). Question too... how many torrents do you have loaded? How many rows are you showing in the listview? About those settings not being saved, I can confirm the bug. I'll look into it when I find the time.

@rd1381: http://forum.utorrent.com/viewtopic.php?pid=446295#p446295 @Szatanek: http://forum.utorrent.com/viewtopic.php?id=58111

All settings save just fine here, whether it be alternating listview background colors, column selections, or category selection. Tested across the most current versions of Internet Explorer, Firefox, Chrome, Opera, and Safari. Heck, I even tested Internet Explorer 6, just for kicks, and (for the most part) WebUI works just fine. I don't know what to tell you. If changing the queue order were as simple as calling an API, it would have been implemented ages ago. It simply isn't possible from µTorrent at the moment.

I just checked, and net.max_halfopen defaults to 8 here using Windows 7 x64. If you set it as high as you're saying, then that's your prerogative.

Hang detection was added only in 2.0.

Dialogs are extremely obtrusive -- especially if they come at the rate at which nemoW's logger message shows up. And no one says release builds are perfect; they're just as best a build as could be managed in the alloted development time.

Well, er, silently reporting statistics (anonymous or otherwise) wouldn't sit well with users, and would only give the tinfoil hatters one more (shallow) reason to shout "UT PHONE HOME". No reason not to just leave it there -- what needs fixing are the hangs, not the logger items. Ideally, if the hangs are fixed, the user wouldn't see the logger messages in the first place. And if the user feels like being more proactive about reporting the hangs (by reporting here or on IRC... or email), they have a bit of information to tie together with their report @nemoW: I wouldn't say having that many logger messages about hangs is "normal", but it's to be expected if the UI really is hanging that often. Which it shouldn't be. If the reports are doing their job, then they should hopefully give the devs a bit of insight into what's causing the hangs in the first place (or where the hangs are occurring anyway). If you wish to report the hangs more formally, you can create a separate bug report thread and explain what you were doing when you experienced the hang (if you actually observed it anyway). And process lists might also be helpful.

Not currently. But it is a known request.

Not currently.