Jump to content

Ultima

µTorrent Helper
  • Posts

    27,924
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by Ultima

  1. IE-only behavior... that never worked for adding by URL unless you tabbed to the OK button yourself. At any rate, it'll return for the next build (along with adding by URL also behaving that way now).

  2. Oh, it's definitely not a full time thing. I'm just maintaining what I can, when I can.

    v0.371 WIP (2010-04-04)

    ~ Change: Blank "Remaining" column if remaining amount is insignificant

    ~ Change: Encode search queries before submitting to search engine

    ~ Change: Hide search bar if search engine list empty

    ~ Change: Split "Add File" and "Add URL" into two dialogs

    ~ Change: Support size/speed units up to exabytes (EB)

    First post.

    Yep, version bump and return of the WIP tag, because I don't want to confuse users on v0.370, but I don't want to keep bumping the version number for each and every WIP build I push out with minimal changes. When I feel ready, I'll push the number up kinda appropriately/arbitrarily ;D

    This build has no major user-facing changes, but it actually involved a cleanup of the HTML/CSS. I can't tell for sure whether I've broken anything, but I did try to minimize the impact -- so I haven't noticed any real issues. No guarantees that I didn't break anything though, so feedback is most welcome.

  3. Requested change made on my end.

    As for adding columns, it still works here in all browsers, so it doesn't seem likely that it's a bug with WebUI. Exit µTorrent, backup your settings.dat, then Esc in WebUI and try again.

  4. v0.370 (2010-03-23)

    + Feature: Torrent job queue order changing (requires µTorrent v2.0.1)

    First post as usual. This feature has been waiting for a release with backend support, and it seems like support was rolled into µTorrent v2.0.1 build 18723 (quicker than I had anticipated). People who have been asking for queue management support -- well here it finally is!

    Edit: I should like... bump the version number or something, since v0.370 has already been declared "stable". This version numbering scheme really sucks, and my constant reuse of numbers doesn't help make it any less confusing for users. Ugh. Next time, I guess.

  5. v0.370 (2010-03-16)

    ~ Change: Slightly more intelligent file priority menu item graying

    * Fix: Category List and Detailed Info Pane visibility/sizing regressions

    * Fix: Status column not re-localized on language change until page refresh

    First post, as usual...

    That first fix should prevent the Detailed Info Pane from being hidden for users upgrading to v0.370. Still no guarantees that old settings will work perfectly (column handling is slightly altered from old versions). Users upgrading from versions older than v0.370 should probably still press Esc to reset all settings to ensure that corrupt settings don't cause bad behavior. Or at the very least, right-click the column headers for the listviews and hit Reset.

  6. Something's broken on your end, not WebUI's. Adding by URL works in all browsers I've tested (Opera, Chrome, Firefox, Internet Explorer). My best guess? Demonoid is behaving stupidly (yes, I saw your previous post, but haven't had time to respond). Try a torrent from here.

  7. They have access to Trac, so the tickets there are visible for them to see. I bug them to deal with some of the issues brought up there every now and then, but that's as well as I can do. Priorities can sometimes dictate that the developers deal with other more pressing matters in µTorrent.

  8. No, using the main listening port works if you disable the alternative listening port. And in fact, it's recommended for the time being because there is a known freeze caused by use of the alternative listening port in µTorrent 2.0.

  9. Apparently, Google Sites limits sites that are generating heavy bandwidth load. I also received the same message as you earlier, but when trying just now, the link seems to be working again. Annoying, but at least they don't seem to be limiting bandwidth using some kind of static monthly limit or whatever (which would cause all links to stop working until the month rolls over).

    Edit: Mirrors...

    http://www.mediafire.com/?1u1dtf02u4nb15d (x64)

    http://www.mediafire.com/?jaizmmhd2aw (Unicode)

  10. I have no problems using IE8 here, but either way, IE8 is just plain slow when it comes to anything JavaScript/DOM. Any other browser is faster than IE8. Heck, even the forthcoming IE9 is supposed to be much faster. My suspicion is that the slowness comes from the column handling changes made to the listviews to make it more language independent and more flexible to add new columns (should the need arise). I'll see if I can do anything about it anyway, but don't keep your hopes up, because honestly, I'm not even doing anything that complicated or heavy when it comes to managing the columns on initial load (I just swap a few DOM nodes around, resize, and toggling visibility).

    Question too... how many torrents do you have loaded? How many rows are you showing in the listview?

    About those settings not being saved, I can confirm the bug. I'll look into it when I find the time.

  11. All settings save just fine here, whether it be alternating listview background colors, column selections, or category selection. Tested across the most current versions of Internet Explorer, Firefox, Chrome, Opera, and Safari. Heck, I even tested Internet Explorer 6, just for kicks, and (for the most part) WebUI works just fine. I don't know what to tell you.

    If changing the queue order were as simple as calling an API, it would have been implemented ages ago. It simply isn't possible from µTorrent at the moment.

  12. If the only thing is those messages - I think those are only for some performance related data messages for the devs. I'm sure they will delete themin one of the next releases.

    Well, er, silently reporting statistics (anonymous or otherwise) wouldn't sit well with users, and would only give the tinfoil hatters one more (shallow) reason to shout "UT PHONE HOME". No reason not to just leave it there -- what needs fixing are the hangs, not the logger items. Ideally, if the hangs are fixed, the user wouldn't see the logger messages in the first place. And if the user feels like being more proactive about reporting the hangs (by reporting here or on IRC... or email), they have a bit of information to tie together with their report :)

    @nemoW: I wouldn't say having that many logger messages about hangs is "normal", but it's to be expected if the UI really is hanging that often. Which it shouldn't be. If the reports are doing their job, then they should hopefully give the devs a bit of insight into what's causing the hangs in the first place (or where the hangs are occurring anyway).

    If you wish to report the hangs more formally, you can create a separate bug report thread and explain what you were doing when you experienced the hang (if you actually observed it anyway). And process lists might also be helpful.

×
×
  • Create New...