Jump to content


µTorrent Helper
  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Ultima

  1. http://forum.utorrent.com/viewtopic.php?pid=573254#p573254

    Known Issues

    • RSS Downloader: Favorites can't be disabled (only removed)
    • RSS Downloader: Favorites don't have Unicode support
    • RSS Downloader: Favorites have crazy checkbox-toggling behavior

    The ball is in the µTorrent devs' court.

    Edit: Other relevant links on backend brokeness:



  2. @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.

  3. v0.386 (2012-01-02)

    + Feature: Cookie manager

    + Feature: Granular WebUI settings reset

    ~ Change: Update MooTools to v1.4.2

    * Fix: RSS feed URLs with pipes cannot be properly edited

    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.

  4. On alpha versions of Opera 12 it's not possible to go to the 2nd level of the context menu (for example from "Label" to "New Label..." - the right click menu disappears when moving mouse cursor to it).

    Probably an Opera bug, but thought I'd mention it here too, just in case.

    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.

  5. @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.

  6. @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).

  7. @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.

  8. 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.

  9. 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:

    1. µTorrent shouldn't even be using "name|url" to specify feeds in the first place. Both parameters should be separate.
    2. 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.

  10. @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.

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

    v0.385 (2011-09-03)

    ~ Change: Allow secondary sorting of torrent jobs when Status is primary sort

    * Fix: Finished and queued seeding torrent jobs are mixed when sorting by Status

    * Fix: Sorting listviews break UI updates in some cases

    First post.

  12. 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.

  13. It seems the favicon.ico has gone missing in the latest version of the webui.

    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).

  • Create New...