A native bencode parser for .torrent files, written entirely using Directory Opus's scripting API, with a strong focus on performance.
Features:
Provides the following metadata :
File name, total file count, and total content size
Creation date and computed age.
Piece size and piece count (exact when derived from the classic pieces field; computed for pure v2 torrents)
Private-flag, Multifile and source tag (commonly used by private trackers for cross-seeding)
Full tracker list (announce + announce-list, de-duplicated)
Comment, Created by, Publisher and Publisher URL.
Version, meta-version (if any).
Encoding field if any.
Info hash (SHA-1) and, for v2/hybrid torrents, the v2 info hash (SHA-256)
A ready-to-use magnet link (btih for v1, plus btmh for v2/hybrid)
Correct text decoding for non-UTF-8 torrents, honoring the torrent's declared encoding/codepage, with user's configurable override per encoding/codepage.
After installation, you can access all the columns as usual, for display, filtering, infotips, etc.
Notes
Since v1.0 was developed rather quickly, there may still be a few bugs to iron out. Feel free to let me know if you run into any.
If a torrent declares an encoding that isn't supported by the Opus scripting decoder, the script will fall back to UTF-8 instead of throwing an error (a warning will be shown in the Script Log).
You can override any encoding/code page with your preferred one through the built-in configuration dialog, accessible via Configuration in the Script Management window.
Thank you! this is indeed much faster.
For Dopus, this might already be as good as it can get.
However, compared to TC's plugin TCTorrent.wlx, the gap is still exponential.
I test a folder containing 10941 torrents.
In Dopus, your this jscript, It took 59 seconds.
while TC, TCTorrent.wlx64, only 7 seconds.
I would look into why it's different before making any assumptions about the cause (e.g. it may be caching previous results), but FWIW you can write custom column handlers for Opus in non-scripting languages if you want to. The API is the same as the one for File Explorer.
How are you measuring the times? I know it's easy to do in Opus, but how are you doing it in the other program? Honest question, I haven't tried that yet.
From what I can tell, that plugin is faster, indeed. However, it doesn't support v2 or hybrid torrents, and it also fails in some cases when the encoding isn't UTF-8.
Not so fast
There's still a way to do it faster via scripting.
Basically, it consists of using a helper script written in a language that's faster than JScript (e.g. Go), moving the whole processing logic and running a local server in it, and then simply communicating between Opus and the server. In fact, I already use this approach in some of my other projects (though I haven't shared them), and there's a significant performance improvement compared to doing the same thing natively in pure JScript.
That said, I do think it's kind of overkill just for parsing torrents, since I wasn't really considering scenarios with 10,000+ files to process.
