Established Members
  • Content Count

  • Joined

  • Last visited

Everything posted by jewelisheaven

  1. aka.. Ctrl-F (just find) I only really would like to see an easier "merge" option. My method there is currently scripted, so it's not a BIG deal, it's just tedious. That and I can't think of other shortcomings when dealing with (other) bencoded data not already covered here on the forum. Can it be made iterative? Are you still quietly working on a new version? Are you planning on adding any easter eggs
  2. Pfft... fixes are nice, what we want are features. Any ideas?
  3. o.O but ... >< inDEED. As usual my mouth needs to catch up to the brain (I never processed all strings were (... it completely skipped my mind, I mean there's text, numbers, and there's list and dictionary containers) Well with the ability for now unicode in/out-put I'm guessing you don't treat it as a special case then? Let it marinate... and stew, and brew.
  4. Binary data would presumably be excluded from a regex? I don't know about a replace *, your idea of the extra box with "key and value" worked after the ideas were proffered. I'm sure after some marination you'll think of something
  5. There's not much to installing it. When it prompts you say yes/no. It will then either copy/move to %PROGRAM FILES%\uTorrent or not. As far as WebUI... you must put it with settings.dat ( ) unless you override
  6. You mean no more ... when it's non-ascii? AWESOME
  7. Esoteric: How does it know there's an error? Or is just because you don't log position doesn't mean you don't keep track of the nesting of keys.
  8. I don't know for sure.. but could you copy your %APPDATA%\uTorrent folder and run it with 1.8 self-contained with "/RECOVER" appended to the exe to see if it's fixed in 1.8? That certainly sounds like a bug... which contrasts with my original understanding of it saving the torrent somewhere it shouldn't, as in the INVOKED user profile instead of the profile of the CURRENT user even though you gave it ELEVATED privileges >< If you really want to get more into it... download Process Monitor from and start logging prior to adding the torrent (Ctrl-E) and log until after you add it and uT is "frozen". Then filter it for the PID of the utorrent.exe process, and look for those "Access Denied" error messages.
  9. I don't think you need to run under a DIFFERENT account. I think you only have to tell Vista THAT you are an administrator... something about "run as elevated user" I think? :/ I've used Vista twice and I didn't get that far in customizing my UI.
  10. Means private torrent. The descriptions were changed recently to make this clear For that site you're a member of they set private=1 so you can't use DHT.
  11. k I'm just saying... it IS faster, whether or not it is intentional. Do you think .. since you're keeping track how far in the file you are right... when you do [15:54:02] [ERROR] Failed to decode the file "O:\Downloads\111\Num\resume.dat.old.1.bad" it could give some sort of notation (for those who understand it) where it is broken :`(
  12. Explorer or blackbox ( both show CPU usage only when treeview filling.
  13. Well instead of using 80-85% of CPU for BFE when the shell is up, it's 62-67% the other missing 12-15 (up to 28 in the .6 line) is in my shell ONLY when the treeview is filling. Those numbers shaving 25% are with no shell up.
  14. Say what? You want me to walk the process in PE? Or you talking about using reload from file (which doesn't exist in .51) and averaging the numbers again? Never mind, I did numbers again anyways... so here's the deal why the numbers are sometimes off by 15-25%, you're doing some overhead in the shell exe(primarily shown in treeview fill) in .6 which is triple which is in .51 (6 vs 18 CPU %) Here's .6R5 with no shell This was validated to be at LEAST 20% faster in 10 runs of each... can I do anything to help you figure out this excess shell calls which cause the processor to not efficiently be concentrated in BFE instead of the shell when filling treeview?
  15. Obligatory speed data You'll notice some speed improvement... is this within expected limits?
  16. Here's one batch.... and here's the other Right click Save as, ^<-_first is 1.3 to 1.5 packed EXEs second is unpacked EXEs_->^ You can find all of .6 in the thread. Also most of the old links still work. I can up anything else you want. All 20 RARs I downloaded are 4.984.105 ... 1.279.094 packed RAR of the UNPACKED exe files is 11% of the 10.722.764 raw size. This compares to 2.367.559 packed RAR of the packed exe files is 45% of the 5.180.876 raw size. I farked up, and only included the filesizes/dates for comparison (if you can't read the filenames) into the larger packed RAR's comment. Ultima: If you don't want me making the unpacked EXEs available please tell me and/or edit the picture out From the notes here, yes the links are what you want. Un-rar the PNG. I'd unpack the 13to15 in a subfolder, as it's 20 folders. v2-6 can be in the current folder, it's only 20 EXE files. Also, NO I did not download the .2 ANSI... nor did I hear about this awesome thing when .1 was out. So unless Ultima provides it that's as far back as data collection can go. Edit: Removed ugly redness
  17. I was talking more of... time to find/replace over # of replacements.... and dictionary/list # vs size I like bar charts, so thanks for that hehe. Now make your own numbers... and compare. FTR: my comp is AMD XP 2000+ 768 MB DDR 400 if you want to start collecting stats. You'll notice that the ED values while easy to baseline due to their easy availability and free nature... Don't quite test the full variability of the display mechanism of BFE over time.... For instance it may take forever to decode a 500 KiB bencoded file with a dictionary with 20,000 keys, but display in an instant (or small fraction of the time it takes to decode). Comparatively decoding a 500KiB bencoded file with 100 keys & 200 sub-values may take exponentially less time to decode but moreso to display due to the sub-nodes BFE renders in the background (For reference my numbers previously 50,228K-4226x36 RED=RAM usage, BLUE=sub-root keys, GREEN=values per sub-root key)
  18. I haven't mentioned how useful the hourglass is > That's how I came up with my "find/replace" figures, if you didn't catch on. I still think it's to do with my limited RAM/CPU in this computer.. but if someone could come up with a function or curve demonstrating the performance times they see. My poor 1.5GHZ single core with 768 MB of DDR 400 doesn't cut it today apparently ><
  19. I already thought of the "merging" idea back when adding data was implemented... but then how does BFE import it(if there's no beginning 'd' and ending 'e' for dictionary... so I thought I would let sleeping dogs lie. It works well enough with Ctrl-X, Up, Ctrl-V, Down, Down
  20. Grr what did you change? Popped up in new posts >< This must be a mod option yes? That you make some changes and it doesn't update the thread, but others do.... pesky piksy pesternomi Edit: Obligatory test values I have to say though I may have bitten off more than I can chew, I forgot about the size of the file >< Trying to use your "Value by Key" Find/Replace on 4226 items is... gonna take an hour by my count. It started at a speedy 42-48 replaces per second, then as the treeview grew (I assume) it's taking longer. It just slowed to 21 every 15 seconds after 12 minutes in. As an aside, I don't know what to do about this, but you can't cancel while "Replace All" is going on... so should the button be disabled? Or would you rather allow Cancel to interrupt the R.A. action? OK so it's done[18:54:05] [Find/Replace] Replacements made: 4226 Could we change the Windows "Alert" sound or whatever it is that plays when R.A. finishes ? Are there any other places where a sound is played? Dude, this is nifty, after any action which expands the treeview, sometimes it's just faster to reload the treeview instead of trying to use any other keybindings to mass change the display, because when it's loaded everything goes back to root display, nothing expanded. Edit: 186 seconds [20:36:16] [Find/Replace] Replacements made: 847.
  21. I have a theory the previous limit was 2^16 yes? With Unicode characters taking up 2 bytes per character that reduces it to 32768... In trying to figure out what else needs to be added, my only wish is you think of some way to be able to include both KEY and VALUE in Find/Replace As far as treeview... Nothing appears out of place, perhaps if you say HOW you changed it it would be easier to test that. * expansion as well as double click and add/remove keys doesn't cause any irregularities I can see. And nothing appears to be different between .51 (even with my triple-scrolling vertical bar) resume.dat... so I think you're safe. Edit: More reverified fun stuff. c/o XIPH and lots of those lossless-philes That's encoding the file after adding an 3067 char comment to the (842,859 bytes) file. It has even more files than I've ever seen but still proves it's keys*subkeys which slows loading not the sheer depth of a specific dictionary or list. Consists of 15581 files. Average size=220.86KB of 3440896 KiB total dataset-size.
  22. If by "output" you mean testing export as binary or bencoded data.. I'm afraid I haven't tested that. I just went through the awesome scripting of loading each of my (moderately sized) resume.dat files 100 times. I did notice... there appeared to be a limit to "value" @ size 30000 bytes? I used multiple right click->paste in previous versions (as Ctrl-V doesn't work) and was able to pump it up to 30228... Is this expected? I can import for example binary data up to 155KiB (as that's the first thing I did instead of bencoded data when I was coming up with a way to restore old torrents from a resume.dat backup)..... If you could explain this arbitrary limit I'd appreciate the understanding.
  23. <poke poke poke> More poking at it Will report back in the morning after the stresstest. With my 3 most common testers
  24. ... Read the thread. OR the sticky. Like I said in the other thread. Here's the link
  25. Any other changes? Did I mention 'Reload from Disk' is highly useful The popup if you made changes to the current file makes it even cooler.