Ultima

Mainly for users who are trying to recover corrupt/truncated resume.dat files. As mentioned in the notes, file recovery recovers only decodable parts of input files. The usual false-positives. v0.7.0.0 Changelog:http://forum.utorrent.com/viewtopic.php?pid=443916#p443916

Fixed.

I've decided to unstick this topic, since it no longer works with the current stable build of µTorrent. Users should upgrade to v0.370.

Known issue, not so much a bug as it is a limitation with what information µTorrent passes along to WebUI. @Snowknight26: http://forum.utorrent.com/viewtopic.php?pid=448274#p448274 But um... since this is being promoted from WIP to "stable" (sorta stable anyway), I'll post an updated build with the (few) changes since the last full release... Get it in the first post.

@Renanbg: @rlmicrosa:Must be related to the altered resize procedure. It's now much more precise about where it places the torrent jobs list -- down to the pixel (or should be anyway, across the browsers that I have tested it with). What that means is that it might be less forgiving with browsers that render a bit unexpectedly. For example, if the list is to the right of the expected position by 1 pixel, it'll flow downward below the category list instead. Definitely happened while I was testing it on some other browsers (IE6... heh, I should stop caring about that piece of junk already). To be honest, WebUI isn't designed for mobile devices. It expects right-click and/or keyboard presses for various interactions, and some things can't be accessed in any other way -- which leaves most (if not all) mobile devices in the cold. As Lord Alderaan suggested, you might be better off using an alternate UI instead that is better suited for mobile devices, but I'll consider looking into mitigating the issue for WebUI anyway. No guarantees or promises about it though.

I suggest you take a look at all of the timestamps on his post and my reply. I don't think I am obligated to wait around for users to silently edit/correct their posts to which I've already replied just to see if my post is still relevant. But that's completely besides the point, because my reply did more than just point out the insignificance of a ramp-up time of (what was at the time specified to be) 5 seconds. Do you happen to be using an alternative listening port?

http://forum.utorrent.com/viewtopic.php?pid=443280#p443280 Then do elaborate: in what way is the new skin "bad"? Because just saying it's "bad" doesn't tell anyone anything. As for the slow ramp-up in speed, is a 5 second ramp-up time really going to cost you anything? It's uTP's bandwidth management doing its job to make sure the connection isn't getting killed. If you don't like it, then disable bt.tcp_rate_control or something. You just won't get the benefit of minimized latency afforded by the extra intelligence brought with uTP.

Just a news flash: the bug with Opera Mini's regular expressions engine not properly supporting Unicode has been fixed as of 2010-01-29 with the Opera Mini server upgrade to 4.15.2444. Nothing needs to be done on the user's part -- everything should automatically work now for Opera Mini users. Edit: Mirror in case anyone's having trouble accessing Google Sites... http://www.mediafire.com/?g2uwddimztw

This has nothing to do with v0.370, because WebUI itself does not control where files are saved, and torrent adding has not changed in any significant manner since v0.361. The only change is that it now supports token authentication correctly -- which is completely unrelated. Besides which, I've already confirmed that it does add the directory name correctly for the torrent using µTorrent 2.0 with WebUI v0.370. Your problem lies with the version of µTorrent you're running or the settings you're using, not the version of WebUI.

Er, well, I guess the problem comes in two parts: 1. You're using IE (it happens only on IE) 2. I missed one particular instance of the variable when I renamed it (I'm no fan of global search/replace... so I do it manually) Since it's not a major issue, I'm not going to reupload a full webui.zip to fix it. http://sites.google.com/site/ultimasites/files/utorrent-webui.stable.2010012823182420.js.gz?attredirects=0 Grab this file, rename it as stable.js.gz, and replace the copy in webui.zip.

Some regression fixes. I hope I didn't break anything further...

First post, as usual. I decided to bump the version number because I've been refactoring a bunch of code. Most of the effort has been in rewriting the column handling code in the listviews, because they were horrendously unscalable and unmaintainable before. It should be somewhat better now. As a whole, though, the listview code is still pretty ugly, and will still need further refactoring. This build is just a stopping point to take a breather, and to make sure I haven't broken things too horribly. The scheduler and search engine list customization are, as noted in the changelog, 2.1 only, because only 2.1 exposes those settings to WebUI (sort-of anyway). "Slightly more natural keyboard/mouse shortcuts on Mac OS X" means that on that platform, WebUI will use Ctrl+Click to show the context menu, and the Apple/Meta key will be used in place of Ctrl as normally used on other platforms for the usual things (like selecting multiple items in the listviews, or Meta+P for opening Preferences -- yeah yeah, Mac users are probably used to Meta+, for Preferences, but whatever ).

Nope, Falcon and WebUI will run side-by-side; not everybody will need or want Falcon's services.

@SacredCultivator: If you happen to be using µTorrent 2.1, then there's your explanation. Apparently, µTorrent 2.1 completely removed webui.cookie, which is a core functionality in WebUI used for persistent storage of settings across browsers. By removing it, any attempt to set the cookie fails in µTorrent 2.1. Not a whole lot can be done about settings not being saved. As for not reloading on Esc... the reason this has started happening is because the request to store webui.cookie fails now, so WebUI attempts to recover by resending the request (it can't tell the difference between an expired token and a rejected request because µTorrent returns the exact same error code/message in either situation, even though invalid tokens are recoverable problems while rejected requests aren't). Until the request goes through, it won't reload. In the current release, WebUI never stops retrying, which (frankly) is a bit dumb, but I was trying to get a basic framework out, so I just left it that way. I've already modified my local copy to stop retrying after a certain number of failures.

Works fine on my end with 3.6. And I don't know what you mean by editing labels/tabs. @joz: If you're going to preprocess files before sending them to the browser, you might as well just unpack webui.js.gz, search and replace all instances of /gui with whatever path you want on-the-fly, and send the result along to the browser. Or uh, just edit webui.js.gz directly as I mentioned before...

When it's ready. We don't set ETAs for builds.

Not being able to upload .torrent files to v2.0 is actually a Wine bug. As mentioned in that linked thread, vote the bug up so that it gets more Wine dev attention.

And this is the relevant tag already included in index.html/guest.html since that build: IE8 doesn't show the compatibility mode toggle button in the toolbar because compatibility mode is already forced by the markup.

This build should hopefully solve the issue for users where WebUI simply stops updating at all for no good reason, since it will retry requests on failure now (before, whenever it encountered an error, it would stop updating). A bunch of polishing went into this release. I think I've ironed out most (if not all) of the most obvious bugs in WebUI, which should make this build almost ready to replace v0.361 as "stable." Will need to wait for feedback from users though, of course. Divider positioning and control sizing on window resize was completely overhauled, so you will almost definitely need to reset the UI by pressing Esc. Get it in the first post. @joz (if you're even reading this): Although the changelog says "* Fix: Regression in support for rewritten URLs", I haven't changed anything with regards to URL rewriting since I gave you these patched files. I can't proceed until I have more information. And just FYI, if you're really having trouble getting me the logs, you can always change the urlBase variable in webui.js.gz to match your needs, and it'll work just fine.

The only things sent in the peer lists are the peers' IP:port combinations. But again, even if client IDs were sent with the peer list, it isn't a viable solution because uTP isn't planned to be µTorrent-exclusive.

That doesn't make any sense on various different counts. [ul][li]Why should µTorrent not request uTP connections for non-µTorrent clients? uTP is going to be a standard protocol extension that any client can support. [/li][li]Comparing peer ID? That's already assuming you connected to the peer via TCP -- how else would you know what the peer's ID is? So by extension, you are advocating serial connection attempts, first using TCP, then trying uTP. [/li][li]Doing extra checks in the extension header wastes as much -- if not more -- bandwidth just to find out if the peer supports uTP. [/li][/ul] So uh, no. If the peer doesn't support uTP, it's as simple as throwing away that UDP packet.

See the quote in the thread: It wastes more time to wait to try serially and wait for fallbacks to occur. And why would the peer ban? If the peer doesn't understand uTP, it can simply (and in all likelihood, would) ignore the UDP packet. If it does understand uTP, it should understand that this was an attempt to establish uTP connection over TCP.

http://forum.utorrent.com/viewtopic.php?id=63408 It tries them simultaneously, and whichever one gets responded to first gets established first. If uTP is accepted after TCP, it is prioritized, so the TCP connection is dropped in favor of uTP.

Will be fixed for the next release. The problem was that WebUI was dividing the availability by 65535, when it should have been dividing by 65536, because 65536 denotes 1.0 availability. Almost a rounding error, but more like just completely incorrect calculation Which reminds me, I'll need to correct the API docs, since it also states that the availability is sent in 1/65535ths. @joz: Don't get me wrong, I'm not telling you that you absolutely aren't seeing this problem -- just that I can't reproduce it. Going back definitely isn't the optimal solution, because if there is indeed a problem in the way WebUI is sending requests, it'll never be fixed if we don't solve it now, and you'll be forever stuck using an old version. Request logs from your browser (Firebug on Firefox or something, or maybe even Google Chrome's developer tools, which are actually very useful), request logs from Apache (and if logged, the rewritten requests too), and request logs from µTorrent itself (make sure you log only WebUI requests in the Logger tab's context menu). That way, we can see what's going wrong where.

Chances are, Firefox was using a cached index.html then, which would contain an expired token that can't be used on next load. v0.362 only recently fixed this by ignoring the token on index.html altogether, and instead dynamically requesting a new one on each load. Torrent adding was indeed broken in v0.361 because it didn't support token auth properly. Anyhow, good to hear that it's fixed for you!