Updating torrent with new torrent file.

[dezintegrator]

Because of some tv series distributed with adding new episodes in the torrent file, you need every time to stop download -> remove the old torrent file -> add a new one -> set a directory for download -> start downloading. This is inconvenient. (there are some other examples)

I suggest small feature that will make it easier and faster:

when adding new torrent, check if a torrent file with the same name already exists.

If yes, then ask a user something like

"Do you want to update torrent Name_of_torrent(creation date) with the new torrent file(creation date)?

xx files in torrent identical.

xx files are added.

Update an existing | Add new "

When updating, program should do everything that have to do user to update torrent in right way: stop -> delete old torrent -> show default "Add new torrent" dialog (with the old download directory) -> continue.

This is just small(it shouldn't take too much code) useful feature, no unnecessary questions(ask only if we add a torrent file with the same name).

[Ultima]

You seem to be confusing something here. BitTorrent works based around nameless pieces, and the concepts of "names" and "files" are simply laid on top of the piece data based on what is described by the .torrent file. If files are added, removed, or changed, it isn't clearly reflected in the information around pieces -- which is what's important. µTorrent can't determine for you that a torrent contains the same files unless it goes and hashes all the files.

Asking the user to replace a torrent just because it uses the same name as an existing torrent would be completely wrong behavior, and would only lead to confusion for almost every other user who doesn't care for this niche behavior. If you know a torrent is updated, then just remove the existing one yourself as you already do, because going by names is an unreliable method for determining whether a torrent is "updated".

Yes, I realize you're asking for this to show up as a popup confirmation before actually doing it, but that is exactly the problem: torrents can easily have the same name and still be completely unrelated. To show the dialog every time the a name matches, even when it's likely the new torrent isn't an updated version of the existing one, isn't a real solution.

Edit: Toned down post aggro. Post communicated thoughts poorly.

[dezintegrator]

I think (but do not sure of course) that it should not take too much code because all operation that needed for this are common: compare a filename, compare a file size, one little dialog, removing a file. All of this function already used by uTorrent.

I understand that torrent files with the same name is not the same torrent.

And I agree, when I said "files in torrent is identical", it should be "files in torrent with identical names" (and file sizes).

Maybe i have not work with torrent as much time as some people (about a year), but at this period i haven't meet any different torrent with the same filename. I understand that situation with really different torrents and identical torrent filenames could be, but I think it is rarely enough.

Even more, if some files in two torrents, have the same name and the same size this is really rare situation for different torrents.

So it could work in such way: if names of torrent files is identical and some files in this torrents also have identical names and sizes, then ask about updating. If this torrents don't have any file with same name and size, then just add a new torrent.

I think this behavior covers almost all real situations with the same torrent filename and does not provide any confusion for users.

PS: of course it's just suggestion, it is not necessary functionality. I can manually replace torrent(as some other people) but i think we are talking about a little improvement of usability.

[Ultima]

Too much guesswork and assumptions involved in that proposal, IMO. To correctly confirm that a torrent is indeed "updated", µTorrent would have to hash the files -- same thing as simply removing/readding -- and then compare how much of the data is the same. Otherwise, it's a half-assed feature that could well end up screwing swarms over (prematurely kill a swarm's piece supply) very easily if it turns out that it's wrong. Yes, there are already other features in µTorrent that can be dangerous in the wrong hands, but this is different, because it would be µTorrent asking any user whether they want to potentially screw swarms up.