RatioMaster.NET 1.3.0

This release comes from what users reported: torrents now carry on from where they got to, all torrents of one client share one port, and a folder of a thousand torrents goes in at once on every desktop.

Carries on where it got to

A restart used to start every torrent over. Stopping and starting a torrent, or quitting and coming back, started it again from the Finished (%) it was added with, so a torrent RatioMaster had already downloaded announced itself as not downloaded and downloaded everything again. Finished (%) now follows the progress while a torrent runs and is saved with the session, as in 0.43 and in a real client, so a completed torrent comes back as a seed. "Use these settings as defaults" leaves the default Finished (%) as it is.

One port per client

Every torrent of one client announces the same port (#56), as a real client listens on one port for all of its torrents. The port is picked by that client's own rules the first time it is needed and kept in the settings, so it stays the same after a restart, and a port copied out of the running client becomes that client's port. Each torrent used to make up a port of its own, so several torrents of one client from one address announced different ports.

One listener answers for all of them. Torrents on the same port share one TCP listener, which answers each torrent's handshakes with that torrent's own peer id. Each torrent used to open a listener of its own, so with the same port typed into several torrents only the first could listen and the others looked unconnectable. The listener also answers with the peer id's bytes now: it sent the peer id as written in the announce URL, so a peer of a uTorrent or BitTorrent emulation got the text -UT360S-%96%b8... instead of the 20 bytes the tracker had.

The Port and Peers wanted boxes take a value only for a custom identity; in Automatic mode what was typed there was ignored.

Fixed

The update after a download completed could follow the completed announce within seconds, and a tracker can refuse an update that early. It now comes a whole interval later, as in a real client and in 0.43.

A started or completed announce that did not get through was lost, and with it the tracker's record that the torrent had started or completed. It is now sent again with the next update until the tracker accepts it, as libtorrent does.

Tracker warnings were never shown. The log now shows them as "Tracker warning: ...". NexusPHP sites, for one, answer an update that comes too early with a warning and do not count it.

Closing the window did not quit with "Close to the tray instead of quitting" off, the default on Linux: the program kept running without a window, its torrents still announcing, and on a desktop with no tray icon nothing could bring it back or end it. It now quits as File > Exit does, after stopping the torrents.

A stopped torrent kept showing the speeds it last ran at, and the General tab kept showing the tracker key a uTorrent or BitTorrent torrent started with, although those emulations make up a new key every 10 minutes.

Many torrents at once

File > Add torrents from folder... (Ctrl+Shift+O) adds every .torrent file in a folder (#57). The LXQt file picker passes a multiple selection through a text box that holds 32,767 characters, so of 1,000 selected torrents only about 350 arrived.

Adding 1,000 torrents now takes 0.7 seconds instead of 5.5, because the list and the session file are updated once for the whole batch, and a torrent that is already in the list with the same tracker is not added a second time. Start all with 1,000 uTorrent torrents no longer keeps the window busy for 11 seconds: after a search for the running client finds nothing, the client is looked for again only a minute later.

Full changelog: https://github.com/NikolayIT/RatioMaster.NET/blob/master/HISTORY.TXT