Archived

This topic is now archived and is closed to further replies.

Ultima

BEncode Editor

Recommended Posts

I had the filters in the dropdown menu in very early versions, but removed it... just because :P (I'm not really sure why xD). Ever since I implemented drag-and-drop support, I don't think I've once touched the Open dialog... I guess I'll add it back in (though I'm going to continue defaulting to All files).

What kind of test data? A torrent with 3500+ files xD It used to take more than 10 seconds to decode it, but now takes around 1.6 seconds. I'm using an Intel C2D E6600 with 2GB RAM, and don't have access to very old machines to test, but I'm pretty sure it'll be slow. I think I managed to improve bdecoding speed by another 15% since 0.4.1, but remember that 15% isn't much anymore, considering the fact that it's sub-2seconds that I'm comparing now. I don't have old machines in mind so much as I do have just general optimization in mind.

Share this post


Link to post
Share on other sites

Blah! Now you have me wanting to make "impossible" files to see how it compares on my system. I thought 1200 files or 200 keys was "alot" since you rarely see that many in legitimate torrents. Read as: GOOD PROGRAM, and I want to break it :P

Edit: here's a screencap of the resume.dat for 1.8 and only 635 torrents loaded :/ Is that expected since each torrent now has ~50 subkeys? Comparatively the 2nd picture is 4201 torrents in the 1.7 stable. The 3rd is process explorer showing vital stats for the editor during opening/decoding. ... 778 vs 620 entries decoded per second according to ROOT keys * entries / TreeViewFill time

utbencode071227tasqx6.th.pngutbencode07122717ee9.th.pngutbencode071227ramjs0.th.png

Also during decoding process the editor only functions near max CPU usage in 9-15 second increments... is this the actual decoding of each root key?

Share this post


Link to post
Share on other sites

That's rather slow :o I'm running out of ways to optimize the decoding algorithm and treeview filling process -- it's probably at (or rather close to) the limits of what the scripting language I'm using can do.

I'm not sure what's up with the "segments" in decoding -- my CPU usage graph plateaus until it finishes decoding so that in the end, I see a trapezoid of some sort.

Share this post


Link to post
Share on other sites

Well the only reason i asked was because it didn't align completely, or totally with MY CPU usage. The sample 1.7 resume.dat completely freezes my CPU (80% usage spike) for 1-1.5 seconds every save of it due to the hashing.As far as the speed... that's the same as your sample decode, 620 keys per second for 2 seconds is ~ your sample number. (4201*36=151236/243.705=620.5 AND 635*50=31750/40.809=778)

I gave reference values and primary keys off the root as well as subkeys for verification. ;) In any case, this will have saved me HOURS when I am finally able to have time to futz with migrating this to 1.8 -> (relative paths ftl ugh).

Edit: I forgot HAPPY NEW YEAR! :cheer: ozzies kiwis and others on the pacific rim :D

Share this post


Link to post
Share on other sites

I noticed when you add a list to a list, i.e. putting an item in an "announce-list" list, it comes out as Item -1 when set to bottom instead of top. Thought that might be a bug, also it fixes itself if you click the edit button followed by ok. That little bug aside, great program. Once command line opening came in I set it as a right click option for torrents and associated it with .BEncode files (lets me save Wireshark data as whatever.BEncode and open it in the editor easily). :D

Thanks again.

Share this post


Link to post
Share on other sites

Hah, nice catch. I've fixed it in my build, though I can't say for sure when I'll be releasing it. Between finagling with the FAQ/manual and doing a bunch of other stuff (Real Life™ included), I haven't been able to squeeze much time in for BEncode Editor :P

Share this post


Link to post
Share on other sites

Nah, I'm skipping 1.7.x and jumping straight to 1.8.x for the manual. There haven't been any substantial changes between 1.7.2 and 1.7.6 that would warrant an update to the manual.

Edit: lol didn't realize you were referring to BEncode Editor 0.5.0. I thought you were referring to 1.7.5 of the manual... or something O.o I'm out of it :o

To answer your question: not really :P

Share this post


Link to post
Share on other sites

[sNIP] BEncode Editor v0.5 not officially released -- still undergoing some changes. What was previous posted was (as I expected) not up to par with how I would've liked it quality-wise, so it's been pulled. Newer builds are still available further into the thread if you still want to give them a shot.

Considering how half of the changelog came between last night and now (quite literally -- all but one feature got added in the last few hours), I feel this build isn't as heavily tested as I would like it to be. As such, consider this a beta/RC (sorta unstable?) build. If no complaints crop up... well, consider it sorta stable then xD

Heh, just noticed that someone else stickified the thread :P

Once command line opening came in I set it as a right click option for torrents and associated it with .BEncode files

Yep, file association was my main motivation for implementing command line loading in the first place :)

Share this post


Link to post
Share on other sites

A sticky well deserved... I'm not sure if this is relevant but it appears that .5 resolved the 15 second interval decoding blocks... however I must have missed the memo.. since when did you HAVE to re-pipe output back to the decoded file when click-drag is used? There also seems to be some timing issue related to that 500000 seconds? that's almost a year!

As always I have pictures for you... compare to the old numbers.

bencode5ut3aq1.th.pngbencode5ut32qe2.th.pngbencode5ut33pa4.th.png

bencode5statsay1.th.pngbencode5stats2qn7.th.pngbencode5stats3ad9.th.png

Aside, YES I know scheme is wonky, but I've been using this for 1.8 colouring-testing, and well.. GREEN appears to be a lighter theme while still being NON-white, but still dark enough so as to not cause eye strain :D

Edit: 1.2 - 1.8 ratios were obtained (old decode times / new decode times) so .. 55-83 % increase in speed?!?!?! Or did I forget something about basic math, lol BRAVO!!

Share this post


Link to post
Share on other sites

Hm. Those kind of numbers make me worry about whether my decoding algo got b0rked somewhere along the way O.o

Can you post a copy of your resume.dat for me to mess around with? I'll edit the link out for you as soon as I grab it.

since when did you HAVE to re-pipe output back to the decoded file when click-drag is used?

What do you mean?

Share this post


Link to post
Share on other sites

Drat I don't seem to have an email for you. Sure I'll upload it. I told you though it's just decoding what I sent it. [sNIP] is the dat file. For the pictures, the double encode/decode and display blocks were ONLY experienced when I click-dragged the file into the BFE window. Note the log (could you make a menu option or context menu for "copy log" so pictures aren't necessary?) only shows the 500K+ for those operations. File->Open operations only show one decode and treeview display process. Did you want my other file... with the 50 subkeys per file for 1.8?

Edit: For clarity, BFE is re-saving the files you click-drag into the window. (thereby resetting the last modified time of this resume.dat for ex, which hasn't been touched since my last picture of it).

Share this post


Link to post
Share on other sites

lmao 4MB dat file... xD

I'll take a look at the stuff you've mentioned. Thanks :)

Edit: I can't seem to reproduce the problems you're experiencing...

Share this post


Link to post
Share on other sites

i TOLD you... 4201 loaded torrents, oi! You'd think after all the constructive criticism I've contributed you'd take my word for it without seeing for yourself :P As I said the double blocks and HUEG numbers only exist for click-drag loaded files. OH! i'm running Unicode btw.

Share this post


Link to post
Share on other sites

Question: did you (or something on your computer) happen to be pressing Ctrl+S or Ctrl+R while it was decoding? If so, then that's the source of your problem. The reason lies behind how I'm hooking the hotkeys. In reality, I'm not using normal per-application hotkeys (via accelerator tables). What I'm using are global hotkeys that act like normal hotkeys by detecting window focus. The only problem is, when the application is busy (decoding), it won't properly unregister the global hotkeys, and it'll keep acting on them. Net result? Possibly what you see.

I might be able to get it to use accelerator tables, but that'll have to wait a few days -- I'm going to be busy tomorrow :P

Share this post


Link to post
Share on other sites

So the entire time of decoding global hotkeys Ctrl-R and Ctrl-S are recognized (I presume also the rest of them, ^F ^H Ins Del Alt-Enter)... sure I'm always awake spidering the forums :P No need for a new update as long as I know what NOT to do..... Do my numbers stand up.. With the same testfile are you experiencing ~50% decreased decoding time vs. .41?

Edit: Are you sure it's not just Ctrl being recognized as down... I do frequently Ctrl-Tab Ctrl-Shift-Tab because in my general firefox session I have ~ 40 tabs...

Share this post


Link to post
Share on other sites

I still have only 15% improvement (though that equates to 2.8 seconds of improvment in decoding your massive resume.dat -- 18.8 vs 16). It might be because of my computer specs? I'm not really sure. Either way, the decoding seems fine, so I the performance boost looks legitimate to me if those are really the numbers you got.

It's definitely not the Ctrl key, because Ctrl does absolutely nothing in BEncode Editor :P

Have you tried the raw inputs and file importing? How about exporting? I feel like they need more testing :o

Edit: BTW, your .dat file still amazes me as to how many keys and subkeys there are. It's so much that after expanding all keys, Windows runs into some kind of treeview limitation whereby it won't allow you to scroll any further down even though there are clearly more items below what appears to be the last item (when you press End on the keyboard). Heh.

Edit: Which reminds me... One thing I'm feeling the need to note is the fact that adding the "double-click edits the item" feature causes the treeview expansion (pressing * on your numpad on the ROOT item) to slow down VERY dramatically. Nothing I can really do about that unless I remove the double-click support, unfortunately. *shrug*

Share this post


Link to post
Share on other sites

Ctrl+R is a keyboard shortcut for reloading the treeview (that reload button). Yeah, it's not documented :P

Raw input is in the Add and Edit dialogs (you'll find it in the Type dropdown).

Email? What for? I don't really have a public-ish one at the moment -- only ones I use to sign up for random sites to avoid spam in my personal inbox ;D

Share this post


Link to post
Share on other sites

Hi Ultima, I just wanted to drop a note in here saying "Thank you very much" for your editor. It turned out to be a handy tool in solving all the problems with my corrupted .dat files which I describe in this thread.

FYI: I used BEE 0.4.1.0 (unicode) on a win2k SP2 machine, and it worked flawlessly.

So kudos once again and keep up your good work :)

Share this post


Link to post
Share on other sites

I'm glad it's been of use to you :)

Another v0.5 build! Unicode and ANSI. It would be nice if someone on pre-XP would test this build to make sure hotkeys still work on those OSes.

Changelog

v0.5.0 (2008-01-20)

+ Feature: "Item" menu with associated keyboard shortcuts

+ Feature: Copy Logger tab items with Ctrl+C

+ Feature: Double-click to edit item

+ Feature: Export data from selected item

+ Feature: Import external file as binary data

+ Feature: Input raw BEncoded data directly or from an external file

~ Change: Add .torrent and .dat to dropdown list in Open/Save dialogs

~ Change: Faster bdecoding (~15% improvement over v0.4.1 in tests)

~ Change: Miscellaneous polish to Find/Replace

~ Change: Use accelerator table instead of global hotkeys

* Fix: "ITEM -1" when adding child list/dictionary to bottom of list

* Fix: "Reached beginning/end of document" message sometimes shown twice

* Fix: Combobox not showing options in dropdown on pre-XP systems

* Fix: Strings can replace integers in Find/Replace

* Fix: Typo in Logger entry for BEncoding

* Fix: Using "Find Next" sometimes returns focus to wrong window

As you might've noticed, I haven't yet updated the first post -- that's because I'm letting you guinea pig for me before I make it official 0.5 :P

Just a quick note... Using accelerator tables has made the hotkeys (sometimes) less responsive (meaning that they don't always work every single time -- it may take several presses). There isn't much I can do about it, but at the least, it's preferable over the ugly "hack" that global hotkeys was (I've been meaning to get rid of it for a while anyhow). Feedback please! :)

@jewelisheaven: F5 was actually another alias for refreshing (it did the same thing as Ctrl+R too). In the end, I decided to remove both hotkeys entirely because the feature itself (reloading) is almost never needed. I myself have only used it to debug some features to make sure items/text are added/modified properly. All it does is reload the treeview -- it doesn't even reload the file from disk. I'd say it must've been dumb luck that you never ran into the global hotkeys' drawbacks before :P

Share this post


Link to post
Share on other sites