My actual internet connection has a slow upload speed, so 5 upload slots per torrent (the actual permitted minimum) is not

ideal in my case. I hope you can allow us changing that number to 1 .


In sequential mode, i would like to set progress limit percent to 0.1 , but right now that option doesn't allow decimal numbers.


For more tweaking / testing , i wish you can allow 1 as the minimum value for these settings:

-DHT maximum simultaneous searches (The actual minimum is 10)

-Peer connect / login timeouts (The actual minimum is 5 seconds)

-Maximum concurrent outgoing TCP / UDP connection attempts  (The actual minimum is 2)

-Maximum peer connections per download ( the actual minimum is 5)



Thanks Mr Kevin for your amazing software.

Are you on dialup?

Nope. I'm using ADSL.

- lower than 5 slots per torrent: I have practically maxed out all my limits and I'll tell you how Tixati handles low upload situations. It seems leechers will get 0 KB/s for a long time followed by a short burst. It shows up as 4KB/s. If there's enough bandwidth they'll continue at 4KB/s minimum or drop to idle 0KB/s. So Tixati will not transfer at a ridiculous 1KB/s or lower speed. It's fine

- In sequential mode 1% limit: Is it the setting that says how much of a torrent must be downloaded before sequential is permitted? That might work if there're 50+ peers, however I'm grateful the developer added limitations after my feedback (you can find the proposals here). Bittorrent can only work well if there're many peers and they download random pieces. This ensures that all downloaders taken together have 100% of a torrent, even if none of them is above 10%. If everyone downloads sequentially then it is enough for one person at 100% to leave to kill the torrent: because nobody has the piece between 99%-100%.
It makes sense that there're sequential limitations by default, I hope you understand. I do not disagree with your idea, it can work fine if there're enough peers to support this behaviour.

-DHT maximum simultaneous searches (The actual minimum is 10): I know myself this can take a lot of bandwidth. However setting it too low can cause transfers to take ages before they find peers, because DHT searches are queued or whatever. Instead I think DHT activity should be repriotized: freshly initiated torrents have short intervals between searches while long-running have long intervals. Maybe let torrents with many peers refresh even less often.

-Peer connect / login timeouts (The actual minimum is 5 seconds): this doesn't cost you any bandwidth, instead it limits the concurrent outgoing slots below

-Maximum concurrent outgoing TCP / UDP connection attempts  (The actual minimum is 2): honestly, how long would it take you to start loading a new torrent? 2 would cripple Tixati even if you had 30 torrents added

-Maximum peer connections per download ( the actual minimum is 5): In order for bittorrent to know what pieces are rarest and to distribute your downloading efforts in the best way possible, it should be connected to as many peers in a swarm as possible: for the health of the torrent, see the 99%-100% explanation above. While that's overly optimistic, ideally you'd still be connected to enough peers to have a representative view of the swarm. Keep-alive costs are negligible, it's possible that reestablishing connections is costlier than keeping them alive (connection establishment handshake, ask for download status, list of pieces)

I don't want to put you down with the above critique, but you're in the territory of "Do you really really know what you're doing?"

Hi notaLamer ,

I don't mind to be criticized. It's expected to see someone saying "No" when you want a new feature, because he probably doesn't want to see the program behaves in a different way than what he is used to. But here i'm not asking for any change in the program behavior, nor asking to change the default look or settings. So really this should not bother any Tixati user.

Anyway, im going to answer to your critics one by one :

1- Lower than 5 slots per torrent: Since my upload speed is slow, i prefer to have as less peers connected as possible while seeding (to not have extra unnecessary connections) . Setting that value to 1 is possible with some torrent clients , but for now it's not possible with Tixati.

2- Sequential Mode progress limit percent : It's not about how much of a torrent must be downloaded before sequential is permitted, it actually defines the percentage of file (not the percentage of the whole torrent) data that must be downloaded in sequential mode before starting normal mode for that file (whom you checked sequential option for it). So what i'm asking for, is being able to stop sequential mode right after downloading 0.1% of the file (just what's needed for playback). Which is the best for the swarm's health, especially while downloading a large media file (Users can set that vale to 100 to download the whole file in sequential mode if they want). If the option to prioritize the download of first and last piece wasn't removed, i would simply use it instead of downloading 1% of the file in this case.

3- DHT maximum simultaneous searches: I just want to try setting that value to 1, others can set it to higher numbers if they want.

4-Peer connect / login timeouts: I know it has nothing to do with my bandwidth. I just want to try setting it to lower values, so Tixati can wait less time before connecting to other peers.

5-
I would like for example to set that value to 1 for TCP while making UDP Maximum concurrent outgoing connection attempts high (and trying doing the inverse as well).

6- Maximum peer connections per download: I have that value set to 15. However, i want to be able to set it to 1 if i wish.

In resume, i'm not a newbie, i just love freedom. And that's why i like programs with advanced settings like Tixati.