Torrent ids change upon restart

[mechanic]

The torrent id can change when transmission is restarted. The torrent id appears to be an integer specifying the torrent count since transmission started. This can be problematic for users of the rpc interface.

Here's a scenario. If transmission has been running for a while and the number of torrents is at 500, but the oldest 100 have been removed, the remaining torrents have ids 101-500. I make a request to get information about torrent id 101. Transmission gets restarted and the torrents now have ids 1-400. I make a change to torrent id 101 using the information I retried before the restart, but the id now points to a different torrent.

I'm going to be using the torrent hash from now on, but either the docs need to warn about this, or ids should be persistent.

[charles]

This has been documented for a long time.

​http://trac.transmissionbt.com/browser/trunk/libtransmission/transmission.h#L1077

1077	/**
1078	 * @brief Returns this torrent's unique ID.
1079	 *
1080	 * IDs are good as simple lookup keys, but are not persistent
1081	 * between sessions.  If you need that, use tr_info.hash or
1082	 * tr_info.hashString.
1083	 */
1084	int tr_torrentId( const tr_torrent * torrent );

[mechanic]

The source code is not documentation for people using the RPC interface. The ​spec should include the warning.

[charles]

Note the `source' references in the spec that refer readers back to the details in transmission.h

[fguillen]

But using the "tr_info.hash" or "tr_torrent.hashString" is not a solution because it can't be used them to "get" a torrent information due the "id" is the only way we can call the method "torrent-get".

As I said in the issue:

• https://trac.transmissionbt.com/ticket/5152

My application is trying to refresh the information of a torrent, let's say the torrent "101", but transmission is getting me back the information of another torrent because this "id" is now owned by other different torrent.

Using the "hash" or "hashString" would be a solution if the api methods are able to receive this values as the identifier of the desired torrent.

[fguillen]

I think this "ticket" should be "reopened", if we can't trust in the "id" as an UID for each torrent then all the commands those use this paramater as identifier become useless.

Suggestions:

• ID should be permanent and never repited
• User another identifier for the API commands like the "hashString"

[jordan]

See section 3.1 of the spec, using the hashString as an identifier has been supported forever.

[fguillen]

You're completely wright, I misunderstood the documentation.