Ultima

http://sites.google.com/site/ultimasites/files/utorrent-webui.webui.2009112718062476.js.gz?attredirects=0&d=1 Download this file, rename it as webui.js.gz, and replace the corresponding file at the root of webui.zip. Not as much testing as I should have (I had to step out for a few hours), but this is just a quick fix On the plus side, I also made it so that the "Checked" status also shows the checked percentage. That is, instead of showing "Checked ??%", it shows "Checked 32.7%" or whatever now.

Hm. I can definitely see that bug creeping in based on the code... I'm looking into fixing it right now, stay tuned. (Should be fixed in my copy, but doing some testing)

Development isn't linear. This is an alpha for µTorrent 2.1, not an alpha for all of µTorrent.

You're right, the ticket wouldn't have been closed if the fixed build weren't available for public testing.

Indeed, I tested it on Opera Mobile v10.0 for Mobile IE when it came out a little over a week ago, and it works fine. Didn't feel like updating the first post because it would bump the thread for such a minor change, but oh well, might as well, since this thread is already bumped by these posts

♥ IE

No, the µTorrent scheduler can't start µTorrent. At any rate, regarding RSS, please respond to my post here.

http://trac.utorrent.com/trac/ticket/68 Correct. It's been a longstanding deficiency with adding by URL. It will be addressed somewhere in the future.

Cool, but that still won't solve Snowknight26's problem natively I guess Lord Alderaan's multi-user shell is indeed best suited for this.

Not really, because WebUI isn't really designed with multiple users in mind -- see the fact that it allows only a single login to begin with.

For Palm webOS users, there is a bug with the browser that prevents users from logging into sites that use basic HTTP authentication (like µTorrent's WebUI backend). The only way you can log in is to visit http://username:password@ip:port/gui/mini/index.html (or wherever you installed MiniUI). So as a recap, I'm tracking a few bugs in various mobile browsers: [ul][li]Opera Mini: (Thread) Broken regular expressions engine that can't handle non-ASCII characters. This causes the browser to not properly load the torrent jobs lists if any torrent job has a non-ASCII character in its name. Edit: This 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. [/li][li]BlackBery OS Browser: (Thread) Submitting a form to an iframe using the POST method fails on BlackBerry OS v5.0. This causes .torrent file uploading to fail. [/li][li]Palm webOS Browser: (Thread) Unable to log into sites using basic HTTP auth via the browser prompt because of a(n apparent) bug in the browser's Base64 encoding routine. This causes an endless username/password entering loop when attempting to visit µTorrent's WebUI. [/li][/ul] If any of you are using those browsers and are experiencing one of these problems, please join me in the respective thread to complain. Maybe it'll help get them to stop sitting on their hands and start fixing the bugs. Do provide some details for them though, like what device you're using, the software version, etc (don't just join and say "yeah, me too").

No, that change has nothing to do with WebUI. And uploading .torrent files still works fine with 17188.

It depends. If webui.token_auth is disabled, then the above code does not need to be named index.html, and it'll work fine with whatever name you choose. But if webui.token_auth is enabled, then the above code won't work without additional (not so trivial) modification if you wish to rename it to something other than index.html. Leaving webui.token_auth disabled is generally not a good idea. You really should report the bug to BlackBerry, as this is a pretty big bug on their part. Working around it only gives them less incentive to fix the problem. Edit: Eh, reported on the BlackBerry forum here.

Right, so I was just testing image uploading at imageshack.us with BlackBerry OS v5.0, and curiously, it worked. After a bit of digging around in the code to check the fundamental differences between ImageShack's form upload and MiniUI's form upload, I think I've determined the cause of the problem. What MiniUI does when it submits a form is that it targets a hidden iframe element in the page so that the page doesn't change. Apparently, BlackBerry OS v5.0's browser doesn't like doing this for forms using the POST method, so it isn't submitting the form data to the iframe to be sent to the server. The result is that nothing gets sent at all except the request itself. (Aside: ImageShack doesn't have to worry about using hidden iframes because the URL they're submitting the data to does return relevant HTML to be shown in the browser, so it's okay to let the browser load the resulting page. µTorrent doesn't return relevant HTML after a call to /gui/?action=add-file, and honestly, it shouldn't need to either). If my hunch is correct, then this is definitely a bug in BlackBerry OS v5.0's browser, as usage of hidden iframe elements is a very common AJAX technique used to submit form data with files, without reloading the page. I would bother BlackBerry about it if I were you. Edit: Here's how you can test for yourself: Make a backup of your webui.zip somewhere, copy the code into a new file called "index.html", then place that file at the root of webui.zip. Afterwards, if you try visiting http://[HOST]:[PORT]/gui/ and uploading a .torrent file, it will work. If you try using this snippet instead, you'll find that file upload won't work. The only difference between the two is that I removed target="dummy" from the add file form. (You'll also notice that the "fixed" form ends up redirecting you to a page that looks like {"build":17188}, which is what targeting to an iframe would prevent)

Thanks But I can't honestly say with a clear conscience that I contributed a whole lot -- only fixed a few minor bugs here and there. Even the Speed tab (the largest feature added in v0.362) was implemented by Novik, and integrated by Directrix.

WebUI seems to behave identically to MiniUI here on BlackBerry OS v5.0 -- it simply doesn't work, and packet sniffs seems to indicate that the .torrent file either isn't sent, or it is stripped before it reaches µTorrent. What model are you using, and what is the exact OS version? For example, I'm testing this on a BlackBerry 9500 simulator, using v5.0.0.252 (Platform 2.13.0.54).

Result (BlackBerry OS v4.7): Torrent successfully added. Result (BlackBerry OS v5.0): Torrent not added. So yes, I can confirm that there is indeed a problem with BlackBerry OS v5.0. Looks to me like BlackBerry's servers are stripping out the .torrent file data before it gets sent to µTorrent for BlackBerry Browser v5.0, but not for BlackBerry Browser v4.7. Maybe it's a browser profile related issue (something controlled on BlackBerry's end; see those .rdf files mentioned in the packet sniffs)... I really don't know what else to say. By the way, the requests as indicated in your log show that BlackBerry Browser is actually making the correct WebUI request -- BOLT browser is technically doing it wrong, and it will fail if webui.token_auth is enabled.

I haven't tested BlackBerry OS 5.0 yet (didn't even know it was out), but speculatively, I'd say this is a BlackBerry issue. I don't do anything particularly special when sending the .torrent file -- it simply submits a form with the relevant file. Question: When you click "Add File", do you see anything show up in the µTorrent Logger tab (make sure you're logging WebUI requests in the logger)?

You have some global stop on all torrents -- probably due to the scheduler (though it can also be due to transfer cap limits, or speed testing). See the status bar.

Yeah, known bug.

Whenever you're not sure, stick with the stable release. That'd be 1.8.5.

@Ichpuchtli: Impossible -- not even as an estimate, unless you accept "completely made up numbers" to be a rough estimate. There is no such thing as aggregate swarm information in BitTorrent, especially when you generally don't connect to everyone in a swarm. And this isn't the thread for feature requests.

Only possible as of µTorrent 2.1, which is currently only in alpha testing.

New build up to fix column header right-click regression.

1.8.5 will be replacing 1.8.4 as stable. Why should there not be a release candidate?