Feature request

[Hellowlol]

This is more a wish list then a feature request, I'm prob gonna send a pr for all them.

• Support for webseed and http seed
• Dynamically set a piece size
• Set max piece size (some torrent sites dont like huge torrents)
• md5 check sum.
• allow .api to omitted
• allow options to set when calling the instance
• add upload torrent to torrent cache to the torrent class or util

[idlesign]

Thank you.
Sounds good, yet this should rather be three separate requests, so we trace all of them down one be one.

[Hellowlol]

some ideas on how to calc piece size etc.
https://repl.it/DN1e

[idlesign]

I see no reason for a user to set a number of pieces, as setting it involves manual size calculation from his side to devise a "proper" number.

On the other hand setting size (in KiBs) manually is probably a good thing.

As a whole, I think we better stick to some widely-used predefined values for various file sizes (something like mode auto in your example).

Some useful links:

• https://github.com/wiiiky/libtransmission/blob/master/src/makemeta.c#L89 (Transamission calculation).
• https://wiki.theory.org/BitTorrentSpecification (Notes section under Metainfo File Structure)
• http://wiki.vuze.com/w/Torrent_Piece_Size
• https://torrentfreak.com/how-to-make-the-best-torrents-081121/ (under PIECE SIZE section)

[Hellowlol]

The reason i added this was because some torrent sites have a max size for the torrent files. Reducing number of pieces reduces the torrent size. The calc mode is what deluge uses. I think beta is the best.

Setting a limit on the torrent size would be nice but I'm not sure how to handle it. I see no reason why we shouldn't support it. It's easy and with good defaults we should be covered

[idlesign]

[...] because some torrent sites have a max size for the torrent files [...]

Yes, but the same goal is already achieved with piece size option. How do you expect a user to set pieces number to control .torrent file size without some precalculations on his side?

Maybe we need an option named like target .torrent size to deduce piece size and number from, but this will involve some heuristics.

beta pushes it too hard — to many small pieces on small torrents, and too big chunks on large, both will affect preformance/availability. Also it recalculates sizes every time, and there is no reason to do it, since file size ranges will do just fine. Any particular reason you consider beta the best?

[Hellowlol]

Because of the pieces will be in the range of 1200 and 1800. Unless the file is to small to get the desired pieces or the file is simply to large to get the pieces it want with max piecesize. And if we want smaller pieces size you can set a new max piece size at the cost of more overhead, 16 mb might be over the top :p

It's the follows torrent freaks guide the closest. Seeding a 200-300 gb torrent (not uncommon on tv torrent sites) with 1 mb piece size result in a huge overhead.

[idlesign]

Chunks under 32KiB are not practical considering current bandwidths, and over 16MiB are too havy load anyway.
Let's base on Transmission presets but extend them up to 16MiB, and let's give an option to set actual size. Later we should try to create a machinery handling another max-torrent-size option, so as to be more user-friendly.

[Hellowlol]

I have started on some of the changes i have listed. It needs a serious cleanup and more tests but it shows the direction i want to go. Ill send a pr when im done and you can just pick what you need or reject the entire thing :P, I just wanted to give you a heads up. https://github.com/Hellowlol/torrentool/tree/better_plx

[idlesign]

Ok, I'll watching from time to time.