Features to make certain content available as soon as possible

[forthrin]

I'd like features/options to make certain content available as soon as possible (and notify me when it is in fact available). Let me know if this is already possible with this utility (or native CLI-based Transmission).

1. Download files smaller than n bytes before anything else (global rule for all torrents)
2. Download files one by one, nat-sorted by path/filename (some torrents are shuffled)
3. Make videos (H.264, (H.265)) preview-able as soon as possible (eg. first 30 seconds or so)
4. Make archives (Zip, Rar) list-able as soon as possible
5. Make files matching some pattern inside archives extract-able as soon as possible
6. Make certain fast torrents finish before other fast torrents (See below)

Say we have some torrents, which individually have the following maximum download speeds (Kbit/s):

• A: 20
• B: 50
• C: 100
• D: 5000
• E: 5000
• F: 7000
• G: 8000

Say the user has a 5000 Kb/s line, then Transmission usually mutually slows the fast torrents:

• A: 20
• B: 50
• C: 100
• D: 1200
• E: 1200
• F: 1200
• G: 1200

Provide a way to do the following:

1. Let small torrents, ie. A-C, take all they want, as they do little damage on the total capacity.
2. Give one of the fast torrents, eg. D, the remainder of the capacity, while E-G are halted.
3. When D is 100%, give the remainder capacity to the next one, eg. F. And so on for E and G.

I expected transmission-remote --bandwidth-high/normal/low to do this, but they do nothing of the kind. Either they are broken, or they work differently. The manual does not detail how they work.

PS! Transmission file-index is not very graceful, eg. -g 10- seems to affect all files rather than 10 up. Also -g 0-9999 fails "index out of range", rather than kindly rounding off to torrent.count(files) - 1.

[rndusr]

1. and 2. Should be possible with a shell script as a cron job. Read stig prio -h, stig help filtersmanual and stig help filters.

2. is bad for the swarm though. If everyone prioritizes the same pieces, the download slows down for everyone.

3., 4., 5. and 6. are impossible and out of scope to implement in stig. You can try requesting those upstream: https://github.com/transmission/transmission

transmission-remote is part of Transmission. stig is a separate project.

[forthrin]

Thanks for your prompt reply.

Well, obviously I can just write a small script to 1-2, but I thought it would be better to ask to have it implemented in an existing utility, to the benefit of other people than just myself.

It won't be bad for the swarm unless it's a default in all clients used by everyone, which would hardly be the case. There are already utilities to do things like mount filesystems or stream videos in torrents, and the swarm hasn't collapsed so far. In theory, you're right. In practice, this will have negligible effect.

Arguably a programming challenge, but far from impossible with the proper knowledge of file formats. I acknowledge that on an academic level, torrent technology is agnostic with respect to content. It just relates to bits and pieces. However, in practice, a majority of the content are videos, and often you want to verify that the torrent contents are the droids you're looking for, without waiting for very large files to download. As for archives, the correct (but obviously hard to implement) fix would obviously be for people to share folders rather than dozen-gig archives.

PS! I've tried reporting bugs on the Transmission issue tracker some years ago, but even after a full year there were no comments. So the project doesn't seem to relate to user feedback. If you have some background on this, do share.

PPS! Just so we're clear, stig is a an alternative CLI wrapper for Transmission, right? More user friendly, more features, more powerful. That's the purpose, right?

[rndusr]

I think 1. and 2. are niche features. Why do you even want to download small files before large files?

The goal of stig is to make niche stuff possible, but directly implementing every niche feature would mean adding additional settings and commands. That would make it harder for casual users to find their way through the docs and it would make it harder for me to develop and maintain stig. I'm already pretty sure I'll never be able to implement all the stuff I want for myself.

Inspecting downloaded files would also mean stig has to have access to those files which is not the case if Transmission is running on a different computer. Tab completion for files faces the same issue, but I'm pretty sure tab completion is much more popular than changing behaviour based on file characteristics.

I'm not involved with Transmission development. Whenever I've checked their repo it looked like the maintainers found other interests. I was surprised to see a 3.0 release. Let's hope it won't be the final one.

stig is not a wrapper, it's a client for Transmission's RPC interface. https://github.com/transmission/transmission/blob/master/extras/rpc-spec.txt

[forthrin]

Just to get the small files out of the way, at minimal cost. Or to download as many complete files as quickly as possible, to put it another way. Often this is desirable.

As for 2, once again it's a way to get complete files, one by one, as quickly as possible, like if the torrent contains a lecture, you want to view lecture 1 first, then lecture 2, etc.

Then again, maybe the pragmatic fix is just to get a gigabit connection. Or to be more patient. Thanks for considering, anyway. Let me know if you choose to implement anything.

[rndusr]

Sorry, I don't think those are useful features and I don't even know how a reasonable implementation would look like.

[forthrin]

No worries. Thanks for your kind and honest feedback, and for your continued effort with this utility!

PS! Since Transmission may seem like abandonware, what are the alternatives? Have someone made a well-maintained and well-improved fork, or are there other lightweight and powerful CLI-based torrent clients you'd like to mention?

PPS! Since aMule is also more or less abandoned, I also wonder if someone would make a super-lightweight, protocol-independent CLI client for both BT and eD2k (and possibly others), as they basically do the same (peer-based file sharing).