Ultima

http://forum.utorrent.com/viewtopic.php?pid=573254#p573254 The ball is in the µTorrent devs' court. Edit: Other relevant links on backend brokeness: http://forum.utorrent.com/viewtopic.php?pid=561522#p561522 http://forum.utorrent.com/viewtopic.php?pid=594152#p594152

[L_("ML_DELETE_TORRENT"),this.remove.bind(this,CONST.TOR_REMOVE_TORRENT)], ,[L_("ML_DELETE_DATA"),this.remove.bind(this,CONST.TOR_REMOVE_DATA)] Remove these.

@TheSPAWN: Remove "a.removeand" from webui.js I guess. And this really isn't a scalable arrangement; I can't keep coming to tell you how to remove this menu item every single time I make a change... @LJ50, tmknight: The current versions of µTorrent 3.1.2 should have fixed the JSON encoding bug.

Not sure, though the devs are aware of the bug.

One of your feeds is serving up characters that µTorrent isn't properly encoding as JSON, so no browser can actually decode the string into usable data. It's a longstanding bug in µTorrent.

First post, as usual. The cookie manager is configured in the preferences. Basically, you associate cookie data (say, "cookie_data") with a domain (say, "utorrent.com"), set, and save the preferences. Then from the "Add URL" or "Add RSS Feed" dialogs, you can hit the "Detect" buttons and WebUI will attempt to find the best matching cookie for the given URL. If, say, you try to add a torrent from "http://www.example.com/test.torrent", WebUI will set "cookie_data" as the cookie data to use for this URL when the user hits "Detect". If, in addition to a cookie for "example.com", the user has a more specific cookie for "www.example.com" with data "closer_cookie_data", WebUI will set the cookie data to "closer_cookie_data" instead. For downloads added via the RSS Downloader (by double-click, or by right-click, but not by the favorite filters), WebUI will attempt to find the best matching cookie for the URL as well. Downloads automatically added via filters cannot use the cookies defined in the cookie manager because it isn't something that's integrated into the backend, and the backend is what controls the automatic filter matching.

You can search/replace by key.

Wouldn't know what to say. It works properly when I try the same.

Just tested it, and it works fine. What version of µTorrent? What browser? Any errors in the browser's JavaScript console?

Opera appears to be firing a spurious event*. If indeed the event is supposed to be fired, then the bug lies in MooTool's implementation of one of the events. Either way, it definitely looks like this might be something outside of my control (or at least outside of my patience level for personally fixing cross-browser compatibility bugs). * Technical Details: I'm using a custom MooTools event called 'mouseleave' that's implemented via the standard 'mouseout' event. As the mouse cursor leaves the menu and onto the submenu (that is a DOM child element of the parent menu item), Opera (or MooTools) somehow thinks that the mouse cursor moused over whatever was in the background (when clearly there was a smooth transition from menu to submenu), and fires a 'mouseout' event saying that the mouse cursor left the menu and reached the background (rather than the submenu). This causes the 'mouseleave' event to think that the mouse left the menu, and basically causes WebUI to hide the submenu.

@levak: Known problem. For automatic catching of feed items, that'll need to be fixed from the backend. As far as manual adding of feed items goes, it can be at least partially fixed from WebUI by having it append the feed's cookie string to each URL (details are vastly simplified; it's annoying to add in a technically correct manner). @psikobare: Known request.

@fatila: See the fix I recommended to Sarreq Teryx here -- except for step 2, you should visit http://YOUR_IP:YOUR_PORT/gui/?action=setsetting&s=sched_table&v= instead.

@Anton9121: Why? Because you're asking in the wrong place. This is the WebUI thread -- not a thread for general queries about the API. There exists an entire forum that would serve as a better place to ask your question. I don't myself have an answer, and anyone who might have an answer wouldn't be looking in this thread to answer such questions (if they even look in this thread at all).

gui.delete_to_trash, or just right-click the Remove button in the toolbar and you'll see the option.

@Aramaki: Then you didn't install WebUI correctly. And no, it wasn't always impossible to use the menu. Browsers simply changed they way they interpreted some bits of JavaScript, so what did previously work stopped working on modern browsers. You can still double-click files to change their priorities in v0.370, but don't expect to receive support for such old versions. @TheSPAWN: Look for the string ' free] ' in webui.js. You should be able to figure it out from there.

No, µTorrent can't assume that it's the only one that can add files to a directory. It makes no sense for it to assume that it can always just blast away an entire directory without affecting any other application -- or any other torrent jobs that may be sharing a directory, for that matter. It only makes sense to remove a directory if it becomes empty after you remove all of your own files, and that's basically what µTorrent does (as I recall). As far as slowness goes, that µTorrent removes files individually doesn't explain why it can (relatively) quickly delete torrents if it isn't set to hit the Recycle Bin. The fact of the matter is, the API used to remove to the Recycle Bin is just plain slow.

Then you're not using v0.385. Clear the browser cache. The bug was fixed ages ago.

At the very least, it's clear where in the code this is causing problems, but to get to the root cause, I must ask: from where are these URLs being generated? A "|" character is not technically valid in a URL -- it's supposed to be percent-encoded. I could sorta put a hack in to fix this, but it still wouldn't be guaranteed to always work for all feeds. µTorrent accepts feed URLs without the "name|" portion of the "name|url" format as well, so if the URL itself contains a pipe character, it would still potentially fail anyway. I could start adding more heuristics to determine if the thing is supposed to be a standalone "unnamed" URL, but then if someone puts "http://somestupidfeedname|http://real.feed.url/blah.rss", it still would fail. We could then blame whomever (poorly-)constructed the "name|url" string as the RSS feed, but then we could say the same about the URL you're having problems with (though your example is certainly relatively sane). It all comes down to 2 things: µTorrent shouldn't even be using "name|url" to specify feeds in the first place. Both parameters should be separate. Feed URLs should always be properly percent-encoded. Anywho, that aside, I'll see about fixing things for your particular "name|url" string. Standalone URLs with a "|" character would still fail, but that's probably less likely an edge case to occur.

One of your feeds probably contains a control character, and µTorrent has a known bug wherein strings with control characters aren't correctly converted into JSON.

@Zenshi: See this post -- specifically, the second paragraph of the Notes/Rant section. @cjoenic: Clear the Chrome browser cache?

@gargamon: If the Directories option you mention is missing, then µTorrent Server doesn't support it. As far as network status goes, there is (to my knowledge) no such API. @IAmThePat: Should be relative unless you have a leading slash. You'd probably be better off testing this than just taking my word for it though -- I don't have access to a Linux machine handy at the moment to verify. @Zenshi: No -- not without backend support anyway. @marklodge: Not a whole lot I can do about that. I've never used WebUI-Shell.

Ugh. Seems like all I've been doing lately has been to fix regressions. Hopefully, these are the last of the regressions. First post.

Yeah, just realized what it was (see above edit). https://github.com/asze/webui/commit/dc88a6e03326a7fc5c4f02f108b26e53f965451f This was the fix. At any rate, sorting basically screws things up at the moment. I'll try to get the fixed version out in a not-so-distant future.

I wouldn't know what to tell you. I've been staring at it for the last minute or two and it's still updating just fine. Check the browser's Javascript console to see if there are any errors, I guess. Edit: Nevermind. It's a bug that I already fixed while fixing the Status column sorting.

So, are actually able to see favicon.ico in IE using any of the older versions? The last build to include favicon.ico was the 2010-11-24 build, and I still don't see it in IE with that build (or any older build) no matter what I do. Also, see edit. It'll stand unless you can verify that there is some way to get WebUI's favicon.ico working with IE (because I certainly can't, and don't feel like trying anymore after looking around for a while).