Torrent Parser : Fast .torrent metadata parser

TorrentParser : Fast .torrent metadata parser (v1 / v2 / hybrid)

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.

Requirements:

  • Directory Opus 13.24.1 or later.

Installation:

Download from here

Then install the script as usual.


Usage

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.

Greetings

  • To Opus team as usual.
  • @bytim for the idea.

Changelog

v1.0 (07-jul-2026) :

  • Initial release.
3 Likes

oh! it's useful, thanx
but there is a strange behavior with an "Age" column sorting. does only the first number count?

Thank you! this is indeed much faster. :+1:
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 :grinning_face:
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.

libtorrent can be used to parse .torrent files if someone wants to make a fast implementation

I had a bit of free time today and wanted to test this theory.
Worth mentioning: I'd never tried mixing a dialog, a server, and script columns before.

From my quick tests, it doesn't seem to have any major issues, but it definitely needs a lot more testing. I'd really appreciate it if you could help with that.

Basically, this script add-In runs a helper written in Go and communicates with it through a local server (so now the Unix sockets request actually make sense :grinning_face:).

The speed difference is huge. It can parse a hybrid torrent with 100,000 files in about 100 ms, whereas the JScript version took around 2 seconds.

Since this is just a proof-of-concept, there are still a lot of things I intended to make configurable (for example, how long the server stays alive after being used), but let's first see how this approach is received.

I also haven't decided how the .exe should be distributed. Since I don't know of any other scripts that do something similar, I'm not sure what the policy is regarding including executables in a script package. For now, the script uses a somewhat "suspicious" approach: it writes its own copy of the executable, but only if the user chooses to do so. Probably some antivirus doesnt' like that.

I've also uploaded the Go source code. You can download it from here, compile it yourself (it has no dependencies), and place the resulting executable in /dopusdata\User Data\GoTorrentInfo\helper.exe. Or you can simply let the script install the executable for you. It's up to you.

Other than that, it behaves pretty much like the JScript version. As an extra, it can also be used as a command via:

GoTorrentInfo FILE "C:\my_torrent.torrent"

to parse a torrent and display its information in a dialog, where you can do things like copy the metadata.

Download the test from here.

1 Like

Here's a video showing the huge speed difference between the two.
The first two columns are from the script above, while the other two are from the script in the first post.

2 Likes

No strong objections, especially if source is available.

Viewer and VFS plugins can also run code and we allow those, so there's no reason to be more strict about script packages that use exe components in ways that make sense. :+1:

Nice speed improvement, too, on top of what already a good improvement.

2 Likes

Thanks!

I've just released v1.0. Hope someone finds it useful.
I also fixed a 10 ms delay that occurred on every communication with the helper, so it should be even faster now.
On top of that, I've added a caching system that stays active for as long as the helper dialog is running.

So... are server/helper-based script columns just around the corner? :grinning_face_with_smiling_eyes:

Interesting experiment. Glad that it works.
Touching on this topic: it is possible to create a COM DLL that doesn't need to be registered. Such DLLs can be placed anywhere in the DOpus installation directory, and DOpus could load them at startup and call an exported method from the DLL like "CreateComClass", and then expose the returned COM class to JScript so it can be used to create UI dialogs and custom columns.
That would be an extra way to extend DOpus. But I don't know how much it is worth adding such mechanism to DOpus.