BEncode Editor

[hermanm]

FYI, there's an online Torrent Editor:

http://www.torrenteditor.com/

Doesn't support web seed field, but it works pretty good if you need to tweak some basic things...

[Ultima]

Yeah, I've seen it before. The server chokes on certain large torrents I use to test BEncode Editor.

1. Add, update, remove or change trackers.

2. Edit creation date, created by and comments.

3. Quickly see what is in a torrent before loading it.

4. No technical skills needed.

5. Fast and easy!

6. No programs to install.

7. Change trackers that are no longer running.

8. Prepare an existing torrent to post to a new tracking site.

9. Verify the torrent contains what it says it does.

1, 2, 5, 6, 7, and 8 BEncode Editor has down pat. 3, 4, and 9 are a bit more iffy, but it's not like the properties that the site allows to be edited make it that much easier. Convenience isn't really a factor either, as the site is cumbersome to use... You have to upload to it or link to a torrent file, then redownload the edited file. With that being the case, you might as well download once and edit locally with BEncode Editor (which doesn't need to be installed).

Now, I'm not trying to say BEncode Editor trumps all, but it's just that there aren't much (if any) advantages to using that page. BEncode Editor isn't all that difficult to use, and there are other editors geared toward editing messing with .torrent files specifically that work well (like TorrentSpy or Torrent Loader, though the latter requires .NET).

I'm not saying this to put the site down either -- I still think it's an interesting idea. It's just... not really relevant in the context of this thread.

---

Back on topic... I think the biggest thing I plan on adding for the next version might be command line editing, but that's most certainly up in the clouds at this point. I haven't really touched the editor code since I released 0.5.

[jewelisheaven]

Torrentspy does not edit. It creates / views torrent information. It's what I used for all bencoded data before YOU created the AWESOME B.F.E. I presume you've tried putting up my resume.dat for verification it can handle all bencoded data?

Something to remember... this is a general "bencoded file viewer" if you will. Anything which is bencoded can be used/manipulated. This means it can be used to diagnose packet troubles with tracker/client response (when loaded/saved appropriately) as well as the more common uses (here being uT dat files and torrents). Sure I haven't poked at it as extensively as uT, but then again it serves a much simpler task, which it does well and has continued improving since inception. <3

[Ultima]

Hah, I meant "messing with .torrent files" instead of "editing .torrent files." Post updated accordingly.

Nope, I didn't upload your resume.dat, as that's not a .torrent file I used my previous benchmarking file (the ~500KB .torrent file with ~3500 files).

[Ultima]

In an effort to get more practice with C++, I've begun an attempt in rewriting this editor in that language (heh, not the first time I've tried rewriting something in C++). I just thought it was worth noting that the libtorrent bdecoder is at least 94% faster than my current (custom-written) decoder -- and that's while testing it under a virtual machine and comparing results from there with results running natively on XP. Ridiculous. It eats jewelisheaven's resume.dat for a snack -- what currently takes ~16 seconds for me to decode would take ~1 second with the libtorrent decoder xD

No promises on results, just a progress report of sorts. I'll probably be working on CLI before I move onto GUI this time too, assuming I get enough momentum.

[GTHK]

Go Ultima Go! XD

Even if it goes nowhere, I still thank you for your BEncode editor, now if stupid windows would allow files associated with a program in a folder named "µTorrent", I'd be happier since that name puts it at the top when organized by name .

[jewelisheaven]

I shall believe it when I see it. Remember you are reading with a .... "new" computer. Just because the program/library can understand the 4201 sub-root keys does not mean it will display them any faster...

I just had an interesting idea... do you think Expand All/Collapse All sub-key items would be a useful feature?? I was just looking through some old gmail threads and realized it's a nifty thing to have... perhaps it could be only sub-current node specific? This would save immense overhead with my resume.dat for ex.

[Ultima]

It's nothing that needs convincing; it's a fact that scripting (interpreted) languages are almost always slower than compiled languages (especially C++) in most respects, and BEncode Editor is no exception. It's currently written in *gasp* AutoIt, which isn't exactly the fastest language around (you can't even consider it a fast scripting language).

It currently reads/parses the file directly from disk instead of reading the file to memory and parsing from there -- another slow/bad design that I can't get around because of the native facitilities AutoIt provides to get around that (none). The way I currently have to add treeview items (because of the dumb per-window control limit in AutoIt) is also horrendously slow: I have to keep making expensive/slow DLL calls that are a hell of a lot slower than creating the treeview items natively.

In the end, AutoIt isn't even the right tool for creating something like this, so switching away from AutoIt is probably the logical thing to do. At best, it's helped me prototype the utility. At worst, it's made me too comfortable with high-level languages, making me lose any "edge" I may have previously had (if any) with lower-level languages.

I'm saying this like I'm ditching the current AutoIt version entirely, or that I've made (or project myself to be making) significant headway in the C++ version... Not necessarily so. Simply put, I'm just going to be more focused on the rewrite now, but if any stupid bugs crop up in 0.5.x, I'll be sure to try and fix it. If I fail at the rewrite, I'll simply revert back to AutoIt. Hopefully, I won't, but even if I do, I'll probably have gained something from my experience anyway.

This rant isn't targeted at anyone in particular, by the way. It's just stuff I've been thinking about that pushed me to my decision (with the additional fact that I do need my C++ practice).

---

"Expand all children" is already doable by pressing * on the numpad while the target item is selected (this is a standard Windows treeview thing). "Collapse all children"... I don't really see the point :|

http://forum.utorrent.com/viewtopic.php?pid=299114#p299114

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*

These tidbits still stand -- your resume.dat is too crazy large, so I wouldn't advise your pressing * on the root item. In fact, even pressing * on a child item is still slow (even on my "new" computer). I suspect it's because there is some chain of notifications bubbling up somewhere when * is pressed that keeps forcing a stupid event handler to fire off (the event handler being the handler that intercepts all events on treeviews -- like double-clicks). No, me implementing it manually won't help matters, and it would undoubtedly be even slower (and still cause massive amounts of events to be fired).

[hermanm]

I hear Perl is good for editing binary files?

[Ultima]

Irrelevant...? Being good/bad for editing binary files has nothing to do with programming/scripting language. If the language can read the data to memory in raw/binary form, then as long as it can manipulate the read data, it's as "good" as any other.

[GTHK]

The "Find Next" button is missing from the find dialog in .5, currently you have to type in your query, leave the dialog and use the Find Next button of F3. Bug right?

[Ultima]

Hah, I didn't notice it because it's a bug that manifests itself only during the compilation stage (the preprocessor removes parts of the code that shouldn't be removed). I don't test the compiled executable for anything other than to check that it runs (I can test the application itself in its uncompiled state), so that's why I missed it.

I've fixed the problem, but am making a few more tweaks to the building process, so I haven't released an updated build yet.

Edit:

CHANGELOG:

v0.5.1 (2008-03-06)

* Fix: Missing controls in the Find/Replace dialog

DOWNLOAD:

v0.5.1 (Unicode): http://www.savefile.com/files/1424227

v0.5.1 (ANSI): http://www.savefile.com/files/1424228

[jewelisheaven]

I dislike savefile. >< Uhm, the title bar doesn't seem to update when you create new files by either importing or exporting data. You can prove this by doing said operation to BASE file (title bar is correct) then trying reload... reloads your altered file (with different name for effect) and title bar is no longer correct.

[Ultima]

I don't see what's so wrong about savefile... It doesn't require Javascript, unlike mediafire.com or zshare.net.

Importing or exporting files shouldn't change the title. Importing and exporting are operations upon the currently opened file. Or am I misunderstanding something...?

[jewelisheaven]

But they do change the file. Checking the log you see file was successfully encoded for saving (for export for ex) but you cannot re-load the current file (according to the title bar).

[Ultima]

It exports the data to the file specified -- that's all. That doesn't mean it'll export the data then open the file. Really, it wouldn't make sense to me that a simple export would suddenly change the opened file, since exporting simply means "you, go and make a copy of yourself over there."

[The8472]

Ultima, if you want so speed up the java implementation i suggest you use memory-mapped files files (NIO) and implement it iteratively... and pre-size the hashmaps/arraylists (assuming you're using those) to some decent default values.

And if you want to do fair testing use the server VM and let it do a few rounds before you start timing, JVM loadup and class optimization takes a while. After that java is usually only about 50% slower than C++.

[Stone]

BEncode Editor is written in AutoIt3, it is not Java... And in certain cases AutoIt can much slower than C++, in fact, I can hardly think of cases where AutoIt could be faster than C++. Optimizing the code may not be possible or can be more complicated than rewriting entire program in C++.

Also... I think some people didn't get one of the main reasons of this rewriting in C++

In an effort to get more practice with C++...

[Ultima]

AutoIt indeed As for iterative decoding, it's probably way over my head -- I can't think of any way to do so :/

FWIW, the rewrite is progressing very slowly because of a lack of time, momentum, and general experience with C++ (meaning I have to grapple my way around sometimes), but I haven't given up on it... yet xD The nitty-gritty implementation details that I took for granted in to be done for me in AutoIt are bogging me down a bit now. Bleh

[jewelisheaven]

I don't want to ask a stupid question, but... why don't you just change the file handling to be based on libtorrent? Presumably AutoIT can communicate with C? Perhaps as an interim step to a complete rewrite.

[Ultima]

AutoIt doesn't (and can't) understand C++ data types, so no can do.

[GTHK]

I have a request (or rather an excuse to be lazy). When importing raw BEncoded data and no name is entered, maybe the name of the file (minus extension) could be used when a file is selected. This would be useful when, for example, importing a url-list (followed by a find/replace operation).

[Ultima]

Hah, lazy or not, I thought it good enough of an idea that I implemented it immediately. That's always a good sign, right?

They finally implemented native accelerator tables in the recent AutoIt betas, so I've finally switched over to it. I'm not sure if it's because of the beta itself, or if it's because of the change to accelerator tables (instead of constantly polling the window active state to check whether I should disable the global hotkeys or not), but updating to the latest version of AutoIt has actually improved the overall speed (decoding and treeview filling) by ~10% in my tests. Wee! I've also implemented Ctrl+A for the Logger tab for ease of copying. That's all... for now. Not yet released, just b'cuz ;D

[ibrahim_abid]

Ultima is BEncode Editor open source and if so where i can get the source code

[Ultima]

No, it's not. I've considered opening the source, but I don't feel like doing so just yet.