Ultima

The Files tab context menu is known to be broken at the moment in Chromium. Double-clicking indeed should work. I'm not sure what to say if it doesn't, but if you really need the functionality now, the WebUI v0.380 WIP should work on utserver, and its context menu works (though the tradeoff is that I stupidly broke double-click support too in one of the recent builds). If you decide to use it, do keep the Linux Support section of the first post in mind. Edit: Clarified that the context menu is broken only in Chromium.

Hm? Please rephrase? I'm not sure what you mean... And which progress bar setting are you referring to? There are at least two.

@Krank: Seeing as how WebUI doesn't ever show any message telling you that you're using the wrong IP and/or port, you must be seeing the error from mr sharpoblunto's application. In which case, wrong thread. I've moved your post to the appropriate location.

I do believe Zarggg already covered that. Zarggg's answer was plenty complete. A correction was unnecessary.

@LEVAC109: Details on the config file are included in the docs. A server may be a server in one context, and yet a client in another. This branch of µTorrent is called "Server" because it can be easily run on headless servers, since it doesn't require a native GUI (it serves the GUI over HTTP). All BitTorrent clients act as both clients and servers anyway.

If indeed you really are experiencing a problem with selective file downloading, I don't understand how it's a bug in WebUI. WebUI is only a UI -- it doesn't change how µTorrent behaves underneath. WebUI is working if it's allowing you to change the file priorities, so you're going to have to troubleshoot this in the Troubleshooting forum for whatever version of µTorrent you're running.

Oh. Stupid me... Will be fixed in the next version. Thanks for the report! (This bug isn't only with µTorrent Server, though it happened as a result of my implementing server support) In the mean time, you can work around the issue by entering the following in your addressbar:

Your use case is atypical. I don't see why the logic should be completely changed for an atypical situation. The logic as is works perfectly fine, and has worked for everyone else who's ever used it -- why should it be changed now because the inverted logic seems inconvenient to you? All you're requesting is for the logic to be inverted. That's as simply fixed as just inverting when you tick the box yourself. I don't see why it requires you to force everyone else to follow your use case -- not when the existing logic already satisfies other users. If I've misunderstood, then please clarify exactly what you're expecting.

I don't know what's up with the need to refresh the page. I have been making heavy performance tweaks to the listview in recent days, and might've run into and corrected the problem -- I'm not sure. Will have to see if the problem persists in the next version. The label thing I can't fix even if I wanted to, as I already told you. That'll have to wait until I get my other priorities finished, and the WebUI backend is updated to fully support multiple labels per torrent.

To anyone who uses my build of WebUI with µTorrent Server: If you report a problem in my development thread, do also mention that you're running µTorrent Server. The issue with ambiguity of bug reports goes both ways.

See, you're going to have to be more detailed than that. I can't diagnose anything if I don't even know what version of µTorrent you're running, or what you mean by "doesn't work". Edit: Nevermind. You posted in the Linux forum too. In that case, there's nothing I can do about this bug until the backend is fixed to properly support multiple labels.

The scheduler thing I'm only going to put in the status bar context menu (just like µTorrent currently does it). Slightly closer integration with the scheduler has already been on my todo. I only pushed out the current build without the scheduler stuff because I wanted the status bar to be tested. Regarding the Preferences thing, I agree. It's something that's been on my mind, but I never formally put it on my todo list. I guess I'll do that now.

I've seen that happen before on occasion, but don't really know how to reproduce the problem. Right now, it looks to be working perfectly under Opera (11).

FWIW, you can always try WebUI v0.380 WIP for the time being. According to lithopsian, the Files tab works fine in the latest version I released (and really, the whole thing should more-or-less works fine Linux). For anyone curious about the differences between the utserver webui.zip and my version, look at the changelog starting from v0.371 WIP (2010-04-16) and newer, as utserver's version was forked somewhere in between the 2010-04-04 and 2010-04-16 builds. µTorrent Server's version has since diverged and implemented things in its own way, but they're not greatly divergent enough for the changelog to be irrelevant. There are still things that are unimplemented in my version (like the /gui/?action=getversion request used by utserver webui.zip's About dialog), but most of the major elements should be there.

Nice The advanced preferences section works exactly like it does in Windows, where you have to click to get the input. The reason is that there are boolean and string/number settings, and what shows depends on which one you click. (Double-clicking works for toggling boolean settings too, as in Windows.) Which settings specifically are you having problems with? And yeah, the Peers tab is cool. What I really want, though, is to want to implement RSS support, as that's very heavily requested, and there's no other simple way to manage RSS under Linux. I've been putting it off for so long because... well, the reference implementation (RSS in the Windows version of µTorrent) doesn't suit my taste. Anyway, RSS is high up there on my todo list, and I'm running out of "small" things to do, so it's going to have to come some time. It's probably the main reason why v0.380 is still a WIP.

Yeah, I wasn't able to test Linux compatibility before now without having first installed a Linux distro to test on. There weren't many changes I had to make specifically to support Linux. Mainly had to implement hiding of unsupported options in the Preferences dialog. You may have to clear the cookies by pressing Esc in WebUI. And be sure to clear the browser cache too.

Gobble gobble. A day early, but gobble gobble. RANDOM NOTES: Yep, auto-refreshing of the Peers and Files tabs is finally implemented. In order to prevent massive bandwidth usage, the fastest the Peers tab will auto-refresh is 5 seconds, and the fastest the Files tab will auto-refresh is 60 seconds. They can still auto-refresh at a slower pace if the global update interval is set higher than either one. If you need to manually force a refresh (because you can't wait the full interval), just click the respective tab, or the torrent job, and it'll force a refresh. As a reminder, the Peers list still requires µTorrent 3.0. That UI resize responsiveness fix was from a stupid regression introduced in the 2010-10-31 build (specifically, due to virtual listview support). With that out of the way, in conjunction with the divider drag/drop change, resizing of the dividers and of the window should feel faster now (at least on Chrome, it's extremely smooth). The status bar currently only shows the upload/download speed sections. The other sections (like error, network status, etc.) aren't there. May or may not get to that another time. The right-click menu for the rate limits support the manual override in the preferences, but not all versions of µTorrent support that in getsettings/setsetting. If not manually overridden, the menu shows some stuff not too unlike µTorrent's automatic speed limit menu, but it isn't exact because I don't know the formula/algorithm µTorrent uses to pick speeds to show. Good enough, I say. Linux support is, as noted in the changelog, rudimentary. That is, I haven't done extensive testing. Linux users are free to report bugs and problems here. I make no guarantees about support, but I can try my best.

Right-click in the Files tab.

If I ever feel like checking, cool, but I simply don't/won't make any guarantees about WebUI's mobile compatibility. There are UIs available that are better suited for use on small screens.

Not sure. Running µTorrent as a service should already have done the trick, unless you set it up improperly somehow.

Wouldn't be at the top of my todo list. At best, whenever I get around to implementing some global menubar, I might be able to add it there, but otherwise, you won't find it very likely that a standalone button like this would ever be implemented. Why? Because this particular WebUI frontend isn't designed to be mobile-friendly. It's designed to very closely mimic the desktop UI, down to other desktop-specific UI elements like right-click menus, so there is little reason to have such a button.

Huh. Didn't realize multiple labels per-torrent was implemented. Ugh, that'll probably be somewhat of a pain to implement, due to the many assumptions WebUI seems to make regarding torrent labels being exclusive. The WebUI backend also doesn't itself yet support this properly (it sends a single label for each torrent, even if the torrent belongs to multiple labels). Anyway, I'll keep it on my todo, but I'm not sure when I'll get around to implementing support. Thanks for the heads up!

Yep, I know the index was always supposed to be used. It was implemented just fine in WebUI; it's just that I broke the feature detection, so it didn't list the directories unless Falcon was enabled.

@mrMan01: As I understand it, µTorrent 3.0 requires HTTP cookies to be sent now. Can't say I agree with that decision, as it effectively breaks backwards compatibility with clients that don't support cookies (like yours). If I had to make a guess though, I'd say the decision was made because otherwise, µTorrent would have to keep generating a new session/cookie for each and every request that comes in without a cookie.