Ultima

Indeed, the new features all require at least µTorrent 3.0. The Peers tab doesn't auto-refresh like the torrent jobs list does (it basically behaves similarly to the Files tab, where manual refreshes are required to see current data). RSS Downloader implementation still deferred for the time being while I tackle some of the smaller things on my todo list.

Sorry, the last one is not a bug. Trying to pass it off as one won't get it implemented any more quickly.

Anywhere in WebUI Ctrl+O: Add Torrent from File Ctrl+P: Preferences Ctrl+U: Add Torrent from URL F2: About F4: Toggle toolbar F6: Toggle detailed info pane F7: Toggle category list Esc: Close topmost dialog, reset UI While torrent list is focused Ctrl+A: Select all Ctrl+E: Deselect all Delete: Delete selected torrent(s) Shift+Delete: Delete selected torrent(s) + data

Yes, that's expected behavior. A fix isn't simple, and you'd be hard-pressed to find anyone who actually runs µTorrent that way. The test servers are notoriously bad. Use the DSLReports speed tests if you're having trouble (users in the US can also use SpeedTest.net). You're free to change the skin. Edit: Constant CPU usage on idle seems to be related to the Windows theme. Using Windows 7 and Windows 7 Basic, you'll notice this behavior (slightly lower CPU usage with the basic version), but with Windows Classic, the problem goes away. I do agree that it should be looked into.

FYI, it's already implemented in 3.0. Whether it'll be backported to 2.2 though... who knows.

Yep, I think I fixed that a few days ago actually (after v0.371 was released). The fix should show up in the next version. If you'd rather not wait, here's a patched file: https://sites.google.com/site/ultimasites/files/utorrent-webui.main.2010090223343111.css.gz?attredirects=0&d=1 Rename it to main.css.gz, and replace the copy inside your webui.zip.

With this out of the way, I think I'm going to try to start working on features that target µTorrent 2.2 and above. I actually laid some of the groundwork for RSS several weeks ago, but never made much progress due to various factors, but anyway... The features that still need implementing include RSS, download directory selection, Peers tab, file downloading (potentially, if the backend API is properly done and exposed), and whatever else comes up I guess.

Yah, the scheduler is somewhere on my todo list. Toggling on and off is simple enough, but there's no simple way (that I can think of right now) to allow users to actually edit the times that would make it easy to use on the supported browsers.

Explain "never having worked right."

Hah, glad to see that people continue to find value in MiniUI. With things being hectic on my end lately, I haven't been able to do much with any of my projects... Good to see that there haven't (yet?) been any new glaring bugs reported

Commandline editing (and by extension, batch editing through batch scripts) has been on my todo for the longest time now. It's not easy to come up with a suitable parameter scheme that handles a large chunk of BEncode Editor's capabilities. I'm not sure if/when I'll ever get back to it, but um, it's definitely still there at the corner of my mind. Edit: Probably worth noting that thinking up an appropriate commandline option scheme was exactly why I stopped working on the C++ port too.

Yeah, sorting by status is actually pretty unnatural because I was being lazy about it. Will need to get around to it some other time. Is it failing when sorting on any other field though?

Open settings.dat and find the relevant keys? I'm sure they're stored in settings.dat in a slightly non-trivial manner, so I don't know them off the top of my head. @octopuss: All 64-bit operating systems support Unicode.

FWIW, it should already have been fixed from µTorrent's end 2 weeks prior to µRemote's last update...

Works for me across all browsers I've tested. What field are you sorting by? @moogly: Yeah, that happened after RIM they bought out Torch Mobile, but nevertheless, I think it should still be fixed in the 5.x browser because well... not everyone's going to be upgrading (or will be able to upgrade) to 6.0.

No, it's been reported since forever ago (if memory still serves, that isn't even the earliest thread either). It was always stated that BitComet didn't exhibit the issue, and it was determined that it was because BitComet itself was bypassing the Windows cache. Which is why this was implemented in µTorrent.

"Binary" data contains non-printable characters (like null). "Strings" contain (usually readable) text. Status changes likely aren't easy because µTorrent may take multiple keys into account in determining what a torrent's status is.

... As has been said a billion times now, this is not possible at the moment until µTorrent's WebUI backend adds support. Which hasn't been done. So it isn't there. @pablo81: Confirmed... Will fix in the next release.

This isn't a .torrent file editor.

Not without potentially killing a ton of bandwidth.

http://forum.utorrent.com/viewtopic.php?pid=443933#p443933

Well, no, it wasn't implemented. I did have it on my todo from the first time I added the dialog, but the only sensible one I could think of was Ctrl+U -- which conflicts with a common browser shortcut (View Source). In the end, I decided to override Ctrl+U anyway. Get it in the first post. I'm not sure how dangerous a change "~ Change: Holding Shift while pressing Delete removes torrent with data" is going to be, but I decided to implement it in order to make it closer to µTorrent shortcuts... Still not sure if it was the right choice, but only time (and/or feeback) will tell. "~ Change: Pause unpauses torrents only if all selected torrents are paused" was inspired by Step's suggestion.

http://forum.utorrent.com/viewtopic.php?pid=467550#p467550 Previously discussed. I maintain that this is indeed poorly thought out design, and have been complaining since v2.0.1 was first released with this status bar format.

Well uh, I wouldn't have stated that it didn't work without having first tested it myself. I did try v0.370 with IE before responding, and no, pressing Enter doesn't work for adding by URL, because the HTML for the adding by URL didn't even support it. It did work when adding by file, which I confirmed above, and that's because the add URL form actually had a type="submit" button (unlike the add by URL). At any rate, it's been reimplemented in my code already, so look forward to its inclusion in the next update.

ERROR_NOT_FOUND 1168 (0x490) Element not found.