Ultima

Yeah, I noticed that during development, but chalked it up to a Firefox bug that cropped up in conjunction with the MooTools upgrade. I'm still not sure if that's the correct classification (it may just be that MooTools isn't paying attention to the W3C specs, but I don't know for sure). Either way, I was hoping Firefox would "fix" itself (no other browser behaves in this way), but that's just silly idealism, so I'll work around the issue. For anyone wondering what the exact issue is: When you perform XMLHttpRequest.open(), you can optionally include login credentials with the request. The MooTools Request object wraps itself around XMLHttpRequest, and in the process, sends a username/password with the request. If I don't include a username/password when creating the Request object, MooTools sends undefined instead for the login credentials. I would think browsers should be ignoring the parameters if they're undefined, but Firefox doesn't. Instead, it stringifies 'undefined' and uses that as the username/password, and so every XMLHttpRequest gets sent under the login undefined:undefined. Needless to say, you end up with this bug. The workaround? Send empty strings for the login credentials with all requests if you don't want to override the existing login. Kinda stupid, but oh well. As it turns out, the MooTools devs seem to have known about this behavior, but decided not include the fix by default (it was commented out). Anyway, it's uncommented now, so it'll be fixed in the next release. (Which should be soonish, as there are too many regressions in the last build for me to be comfortable with. Just need to work out some other changes before release.)

Right, not sure what happened earlier when I tested it (I was switching between µTorrent versions, so I probably screwed it up). I'll fix this in the next build.

Adding torrents anywhere, in any way, crashes the current 3.0. Not WebUI's fault. I have no idea what you're talking about when you say that you can't see the directories. Edit: Seems action=list-dirs is another request that requires µTorrent Web (Falcon) to be enabled. Not WebUI's fault either. I've bugged the devs enough about this, so the ball's on their court. Sorry, I'm an idiot.

No bug. The popup is shown only to allow you to select where to download the torrent to. µTorrent, at that point, hasn't yet actually gotten the torrent metadata that contains the file list, so it can't show it.

Yeah, another v0.380 WIP. No different from how there are multiple µTorrent v2.2 betas. It isn't labeled "stable" yet due to its having tons of experimental changes. You can always check the About dialog (F2 in WebUI) to see the build date of the one you're currently running. And in true WIP fashion, I already discovered a few regressions with this build that came as a result of the MooTools upgrade (yet again... seems like very time I upgrade MooTools, there's a break somewhere). Specifically, multi-torrent support for the Properties dialog is broken, and the Files tab context menu doesn't work. Will be fixed in the next build, whenever I get that out.

Trick or treat! Massive changelog (relatively speaking anyway). Finally got around to implementing download path selection several weeks ago. It requires µTorrent 3.0, but the sub-path support is very limited due to a backend limitation. Specifically, sub-paths will not be used unless the sub-path already exists in the filesystem as a directory. Nearly useless indeed, but it wasn't my call. I'll bug the backend devs some more about it, but for the time being, enjoy (At least base path selection definitely works.) People who hate the paging system used in the listview can rejoice, because I finally got around to fixing the virtual listview support. Gone is the need to flip to the next page to see more torrents -- just keep scrolling, and it'll dynamically populate the rest. This is enabled by default for clean installs of WebUI. For users upgrading and wanting this virtual listview behavior, set the max number of listview rows to 0 in the Preferences. Anybody experiencing the issue schnurlos previously reported also have cause for celebration now, because I finally managed to reproduce the problem and fix it. Sort of. I don't like my fix, but a lot of the listview code is a mess already as is. I'm still trying to clean up whatever I can, but it's not simple. Interestingly, this bug only affected listviews because they were using paging. Had the virtual listview support been fixed sooner, this bug might not have been noticed, so I guess it's a good thing I kept putting virtual listview support off. Um, yeah, in other news, this build also has better IE support too (no more need for compatibility view). The changelog tells all.

They aren't encrypted by the client specifically. Doesn't change the validity of Switeck's statement though, as he didn't limit the scope of his not-in-the-clear qualifier to in-client methods only.

One alternative is to use WebUI to set it for you too: http://localhost:port/gui/?action=setsetting&s=logger_mask&v=-1 This works under the assumption that you've set up the login for WebUI, and disabled webui.token_auth (temporarily anyway). Advantage here is that you don't have to get involved with manually editing settings.dat, or restarting the client. Disadvantage is that you have to remember to restore the WebUI-related settings afterwards. Logging to file can be handled via the usual Logger context menu item.

Indeed, did a bit more testing just earlier, and it seems like it may have been coincidental -- or maybe it happens more frequently with more network/disk activity. For the most part, I only get very short hangs, but every now and then, I get hangs that last upwards of 5 seconds. Based on the way I'm stating this, it may seem like it's a rare occurrence, but the fact that several people have been complaining about this in recent weeks indicates that it isn't actually that rare. It doesn't happen for me every time I try changing the settings, but it happens often enough. So the only real problem is figuring out how to reproduce these long hangs reliably enough to debug. Just repeatedly pressing Ctrl+P and Enter eventually induces a hang, and I've reported it accordingly. Seems like alus is sorta investigating it too (he's been seeing hangs on occasion as well). Edit: Alrighty. So alus tracked the bug down to potentially being a problem with closesocket() randomly taking a long time to complete on Windows 7 (the only OS he and I have available to test). Interestingly, I also noticed a while back that all of the reports on this problem were also from users running Windows 7. Not sure if it also affects other OSes based on the more current NT kernels (Vista/7/2008), and so far, I have yet to see any reports from the older kernels (2000/XP/2003). So... just to confirm (Simon100), what OS are you running?

@Simon100: Yes, several people have reported the issue (myself included). Last time I tested it, it appeared to be linked to heavy disk activity (so essentially, high transfer rates). http://forum.utorrent.com/viewtopic.php?id=85484

The specs don't define how files are to be handled by the client. 0-byte files are of very questionable value. They're nothing more than filesystem data, and if exploited, could be a simple way to inundate a user's filesystem with tons of junk filesystem entries instantly. If anything, I'd say 0-byte files shouldn't be "allocated" at all unless the user explicitly tells the client to do so somehow (pre-allocate all files, or some extra option in some menu).

Builds pushed out through the auto-update server are placed there manually. Not every build gets put on auto-update, and even those that are put there are generally given buffer time and a staggered rollout on the off-chance that there's something horribly wrong with the build.

Er, hrm. Intriguing. I wonder how that happened D: Rebuilt/reuploaded. Thanks for the heads up!

He's probably referring to having an API request. Rainmeter is a widget engine, so it probably has its own custom widget to throw the data on screen (it doesn't use the WebUI frontend, only the backend). Without scripting, it isn't simple (if not impossible) to display only a subset of the data, and that's why poiru wants an extra parameter.

... The false-positive is the warning, so of course, if there's no false-positive, there's no warning.

Depends on what you mean by "true". - It probably is true that he saw that message from his anti-malware software. - It probably isn't true that there actually was a virus. Why probably? Because that depends on whether or not his computer itself was already infected with malware. And historically, many anti-malware packages throw false-positives on µTorrent anyway.

Cell phones can use specialized UIs to control µTorrent, yes. This WebUI discussed in this thread is not particularly well-suited for use on mobile devices. Again, you don't have to use WebUI, so there is no reason not using it would harm your computer.

You don't need to use WebUI to download torrents. WebUI is simply used to control µTorrent from a web browser on a remote machine.

Why would you think you need to use it?

Just tested it on an iPhone. WebUI v0.380 looks okay on it (albeit, without any scrollbars on the listviews it seems). I'm not sure what you're referring to. And I didn't really alter the UI resizing code much for v0.380 anyway.

Yep, I know of the problem with Web needing to be enabled. It's really not something I can resolve from the WebUI frontend. I have bugged Firon about it, and have brought it up with a dev. mcdonald has said that stated that it'll be resolved in the future. I should probably note that any features that require a non-stable version of µTorrent should themselves be considered and treated as experimental features, so expect bugs Regarding the duplication, I did run across such a problem while I was first implementing it, but (thought?) I fixed it by the time I'd released it. I don't seem to be able to reproduce the bug.

µTorrent 2.0.x has been released for a while now, with many changes since 1.8.x. Among the biggest changes are full uTP support, UDP tracker support, and a transfer cap. As well, several security vulnerabilities that affect older versions of µTorrent have been fixed. See the changelogs! 2.0.0: http://forum.utorrent.com/viewtopic.php?id=65482 2.0.1: http://forum.utorrent.com/viewtopic.php?id=68992 2.0.2: http://forum.utorrent.com/viewtopic.php?id=72352 2.0.3: http://forum.utorrent.com/viewtopic.php?id=78100 2.0.4: http://forum.utorrent.com/viewtopic.php?id=82840 Download: http://download.utorrent.com/2.0.4/utorrent.exe Yes, this is a tad bit late an announcement, since 2.0.x has been out for approximately 3/4 of a year now, but I guess it's never too late. Adding to this thread for the sake of continuity and completeness. And, I suppose, to notify anybody who's been relying exclusively on this thread for update notifications...

Regarding the titlebar moving off-screen, I'd complained pretty extensively to Firon about the minify button somewhere last month... I do believe someone else reported this problem not too long after recentering was first introduced too. I say it should just be removed, because honestly, I can't imagine anyone needing a way to quickly toggle between the mini and full UIs. Not that Windows Media Player is some kind of model application, but when you toggle between its player and library view, for example, it doesn't bother recentering the UI around the mouse either. It just lets the mouse fall outside the window bounds on switch, which feels perfectly fine to me, so I don't see why it shouldn't be fine for µTorrent too. Edit: Yep, icleolion got to the report first.

net.calc_overhead is "Apply rate limit to transport overhead" with a pretty face.