As I know, "Set CONTENTFORMAT Movies" show video metadata columns，and the metadata values are obtained through the viewer plugin movie.dll,
If we disable movie.dll, all video metadata columns are empty.
So, there must be a way to obtain metadata through a viewer plugin dll.
Importantly, parsing the content of certain files through a viewer plugin should be much faster than through jscript.
If possible, I believe it would be beneficial to open up this feature in the interface SDK.
This is similar to the wdx plugin of TC (TC Content Plugin ).
For example，can I make a viewer plugin torrent.dll to parsing a .torrent file to show its metadata in custom columns?
(I am currently using JScript to parse torrents, but the speed is too slow.)
In this particular case, I didn't initially think that using JScript was the direct cause of the poor performance.So I ran a benchmark comparing a test script I wrote against this script (which I assume is the one you've been testing, since it looks like you're the author). I only modified it to add benchmarking support. The results show that JScript is getting blamed unfairly in this case.
File
FileCount
Total Size
TorrentParser benchmark (ms)
Your script benchmark (ms)
test 1
88776
242 GB
775
26062
test 2
1206
55.8 GB
19
389
test 3
11647
3.38 GB
123
3599
test 4
1
6.07 GB
2
1
As you can see, your implementation has a huge amount of room for improvement. It takes up to 25 seconds for a single file ( ), compared to about 800 ms with my implementation.
The language certainly has an impact, and at some point you may hit JScript's limits. But a lot of it also comes down to how efficiently the data is processed, regardless of the language.
Sure, I guess.
But first, could you provide me with some sample torrents that aren't UTF-8 encoded?
Some that explicitly declare an encoding, and some that don't.
Because if I'm understanding your script correctly, it expects those cases to occur.
Thanks! Feel free to test the script once it's live.
I noticed that some of your examples declare the encoding as "GBK". However, you can't use that directly with StringTools.Decode(). I also didn't want to hardcode mappings because that could easily become an endless task. So instead, I added an option that lets users define their own encoding/code page mappings whenever they run into a specific one. You can access it via Configure in the Script Management window.
I don't think I can make it any faster, to be honest, especially for v2 torrents, which take the longest to parse. But I think the current performance is pretty decent, almost the limit of what JScript can do, IMHO.
), compared to about 800 ms with my implementation.
