Ultima
-
Posts
27,924 -
Joined
-
Last visited
-
Days Won
4
Content Type
Profiles
Forums
Gallery
Downloads
Events
Blogs
Store
Posts posted by Ultima
-
-
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.
-
No, All this means is that the following fixes are in 2.2. and NOT in 2.2.1 (yet)
I do believe Zarggg already covered that.
All this means is that ... it's possible that the changes might be merged to 2.2.1 or 3.0.Zarggg's answer was plenty complete. A correction was unnecessary.
-
@LEVAC109: Details on the config file are included in the docs.
This sounds like a contradiction. Why would people who seek a client want to download a server?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:
javascript:["total_uploaded_history", "total_downloaded_history", "total_updown_history", "history_period"].each(function(id){$(id).setStyle("display", "block");}) -
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).
DISCLAIMER: The use of my build of WebUI under µTorrent Server is neither officially endorsed nor supported by anyone here. If you run into bugs while using my build of WebUI, then the onus is on you to test for the same problem under the copy of webui.zip distributed with utserver to see if the problem persists, before reporting the problem here. If you can't reproduce the bug with a restored copy of webui.zip, then don't report the bug here, as it may not be a bug with µTorrent Server.If you're unwilling to go through the extra trouble that comes with this, then my suggestion is not for you. I wouldn't want to find out that this suggestion is causing more headaches for µTorrent Server devs.
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.
v0.380 WIP (2010-11-24)+ Feature: Auto-refreshing Files list
+ Feature: Auto-refreshing Peers list
+ Feature: Rudimentary uTorrent Server (Linux) compatibility
+ Feature: Set global Run Program
+ Feature: Status bar
+ Feature: Toolbar chevron
~ Change: Add some missing settings and controls to the Preferences dialog
~ Change: Disable toolbar buttons if unusable on selected torrent job(s)
~ Change: Divider drag-and-drop updates control sizes in real-time
~ Change: More intelligent menu item disabling based on selected torrent jobs
* Fix: Allow 'Esc' to work while a modal dialog is open
* Fix: Delete keyboard button or Remove toolbar button use default remove action
* Fix: Improve UI resize responsiveness
* Fix: Restore request failure retry limit of 5
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.
-
Wouldn't be at the top of my todo list. ... Why? Because this particular WebUI frontend isn't designed to be mobile-friendly.
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.
-
v0.380 WIP (2010-11-06)
~ Change: Don't auto-redirect on port change (display message instead)
* Fix: Broken Files tab download
* Fix: Hide separator in Label submenu if no label exists to be selected
* Fix: Ignore uTorrent Web enabled state for 3.0-only features
* Fix: MooTools regression caused Firefox to repeatedly request login details
* Fix: Regression in Files tab menu items
* Fix: Regression in multi-torrent support for Properties dialog
-
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.
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.)
µTorrent Server 3.0 alpha build 27079 (for Linux) - x86
in Announcements (Linux)
Posted · Edited by 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.