Ultima
-
Posts
27,924 -
Joined
-
Last visited
-
Days Won
4
Content Type
Profiles
Forums
Gallery
Downloads
Events
Blogs
Store
Posts posted by Ultima
-
-
Yes, drag-and-drop of URLs, and it certainly still works for me in Chrome and Firefox. Easily testable by dragging and dropping a link into the WebUI window and noting that a torrent job is added to the list.
-
Not from this UI, no, not currently.
-
No, it actually wasn't ever released under an open-source license. Really nothing's technically stopping anyone from de-minimizing the code, but in an ideal world, I would actually open-source the thing. Maybe one day, when I've found a bit of time to clean stuff up. Still I'd imagine someone out there could probably whip up a better interface than I did, and in a shorter amount of time given the availability of quality JS frameworks available...
-
-
WebUI simply passes the variable along to the backend. If you refresh WebUI and still see the %K there, and yet it's not working, then it's a a backend issue (i.e. a problem with utserver).
-
What is "the utorrent folder" you're referring to? The .exe directory, or the settings.dat directory?
-
Please read the posts immediately following the one you quoted.
If you're still having problems with numbers, then you're suffering from a separate problem than was described in that instance. You're going to have to provide more information than "I see the same problem" (i.e. tell me how to replicate the problem).
-
Nope, no way to prevent subfolder creation -- at least as far as I know.
Which leads to my response to your first query... "as far as I know" is why the docs have languished. When I wrote up the original documentation, I essentially had to "reverse engineer" the entire thing by looking at WebUI's requests to the backend because no canonical/official documentation was ever provided by µTorrent developers. That hasn't since changed (still no official documentation coming from devs); what has changed is the amount of time/energy I am personally able to spend on coaxing information out of the devs.
What specifically are you looking for in terms of updates? New fields in list=1?
-
No worries, didn't take your post as a complaint. My primary reason for citing that old post was for the last part of it actually
Anyway, a workaround right now I suppose would be to disable every checkbox option for filters, hitting Apply, then enabling every option you actually do want to use, and then Apply again.The behavior is perfectly consistent and predictable that way.
The rest of the quote was included for color, in case anyone cared to know why it's broken. Quite disappointed that nothing's changed on that front in nearly 3 years now, but I guess that's because there's no one constantly prodding the devs about the design flaw. I'm still not convinced this is something that should be fixed UI-side given that any changes backend-side (assuming the API design is otherwise left as-is) would again break any UI-side fix I do implement.
-
Yep, that RSS funkiness was documented on the release post:
As I've said, it's still incomplete, so you can expect a few bugs/limitations right now. The most annoying issue lies with filter modification. Because the backend is broken by extremely poor API design, various options won't be set properly when you change them. Those who care to know the technical details can see this thread. ... [Y]ou'll have to put up with it for now, but it'll magically fix itself if the backend is ever fixed ... . Anyway, a workaround right now I suppose would be to disable every checkbox option for filters, hitting Apply, then enabling every option you actually do want to use, and then Apply again. -
I pulled this resume.dat up in this editor. The editor does NOT report any hash error. (huh?)
I deleted the last torrent, then saved the file. The fileguard hash value did NOT change.
http://forum.utorrent.com/viewtopic.php?pid=289826#p289826
Please don't stop reading a discussion mid-way without first checking on the resolution. Especially when the resolution came only a few posts after the very post you quoted.
BEncode Editor is to BEncoded files what Notepad is to text files. Just because Notepad can edit .html files doesn't mean it should have to understand web browsers' interpretations the files. Similarly, just because BEncode Editor can edit resume.dat doesn't mean it should have to understand µTorrent's interpretation of the file.
µTorrent failing the file because it failed the hash check doesn't necessarily mean the file was invalidly BEncoded. It just means there are extra validations that µTorrent applies on the data that BEncode Editor doesn't care to do (because it's outside the narrower scope of BEncoding).
WARNING: Make sure you first exit µTorrent before editing these files, as µTorrent rewrites/updates the files on exit. Additionally, the .fileguard key should be removed, since µTorrent will consider its .dat file to be damaged if it is edited and no longer matches the stored .fileguard hash.[h]Final Warning[/h]
This utility is for advanced users. Read the warnings in the USES section, and read them again until you understand well what you're getting yourself into by using this editor. Its relatively intuitive UI can beguile most uninitiated/beginning users, as it has an inherent ability to invalidate many files through wrong and incorrect edits.
BEncode Editor has facilities to allow you to regenerate the .fileguard hash correctly, but it won't hand-hold you through it. If you would rather not just remove the item, then you can hash the top-level dictionary after removing the .fileguard hash from the file using the Item menu, then re-add the .fileguard hash wherever it once was, but set the value to the hash that BEncode Editor calculated.
-
v0.388 (2013-05-28)
* Fix: Broken "Add New Torrent" dialog in IE
* Fix: Broken column width handling in Chrome
* Fix: Broken table scrolling in Opera
* Fix: Table scrolling breaks after column reset
Fixed some low-hanging fruits. It's been over a year, but that's all I've got right now (busy with Real Life™).
Anyway... First post, as usual!
-
-
http://forum.utorrent.com/viewtopic.php?pid=586888#p586888
Broken API design, broken UI. I can't imagine it being more than a trivial bug to fix on the backend (API) side. If someone would bother to fix the backend by having it use simple bit twiddling, this would be work just fine without any work on the UI side, and it would continue to work even as new options get exposed.
-
@icsterm: Last I tried, I was able to replicate the issue in Chrome. Will take a look at it when I get the chance...
@rocketman221: http://forum.utorrent.com/viewtopic.php?pid=586888#p586888
Yes, the API design flaw has been there in the µTorrent backend for quite a while. I still don't consider this a bug in WebUI.
-
http://forum.utorrent.com/viewtopic.php?pid=594152#p594152
As previously mentioned, Unicode support in the µTorrent backend is slightly broken in some places.
-
Does the same option's value change in µTorrent after you change it in WebUI? If so, then it's an issue with µTorrent, and not WebUI.
-
@chris_h16: Monitored folders and Transdroid have nothing to with this WebUI. Nothing I do in this UI can change the way they work.
@CubanMissile: http://code.google.com/p/chromium/issues/detail?id=123150
-
@adriankoooo: Clear your browser cache, and try redownloading WebUI from the first post too while you're at it. The fix made it such that adding by manually inserting :COOKIE: in the URL, and adding with the cookie field populated generate the same exact request to the WebUI backend, so if one works, there's no reason the other wouldn't (or conversely, if one seriously doesn't work, then there's no reason the other should work either).
@mfrazzz: Uncheck Preferences > Advanced > Web UI > Use system fonts. If you're seeing this on Chrom(e|ium) on Linux, then the browser probably still don't have proper support for basic system fonts as defined in the CSS2 font shorthand spec. Read: Not My Fault the Browser is Broken™
@aa_gun: I have no idea what "last fix" you're talking about. And to be honest, I'm not really sure how connection close issues are even WebUI's fault. What WebUI does as far as connections goes isn't exactly sophisticated: it sends a request, reads the response, then sleeps (letting the request object go out of scope, which should be picked up by the garbage collector). If your browser never closes the connection, then maybe the browser holds several connections open for reuse since connection setup/teardown can be relatively costly (and so this should not be any of your concern). If it never closes any connection, and only ever opens more and more connections, then that's a bug in your browser -- not WebUI. I've never observed continuously-opened-but-never-closed connections with any browser I've tested, and all browsers have a per-server connection limit to prevent hammering anyway.
-
Rate Limiting:
If the rate limits are being saved between sessions (reload WebUI), then there's not a whole lot I can do from the WebUI side of things. And really, what do you mean by "not working" anyway? In what way is it not working?
Cookies:
Hah. Inconsistent URI component encoding. To be fair, I've never really used any sites that require cookies, so it's kinda hard for me to test these things carefully. But enough with the excuses
Download this file, rename it to webui.js.gz, replace the one inside webui.zip, and try again.
-
Download this, rename as webui.js.gz, replace inside webui.zip.
-
Not supported in the back end, so no, not currently.
-
Needs backend support.
-
Basically.
µTorrent WebUI
in Web API
Posted
No. WebUI uses basic HTTP authentication, which is in the browser's control. If your browser is asking you to login every time you restart, then that's a browser issue.