Torrent Errors not caught when there are backup trackers

[eldonmcguinness]

I have recently run into an issue with how transmission reports errors, in most cases when a tracker returns an error it transmission puts it in the error property field. Unfortunately this does not happen if there is a backup tracker and the error reported by the primary one is not a communications error. In this case the error is suppressed and the backup tracker is never consulted. An example of this is when you have a torrent that, for whatever reason, has been deleted. Most trackers respond with an "Unregistered Torrent" error which will not trigger a communications error.

This is not a big deal until you try to use tools to interface with transmission, if they are looking to see if there is an error with the torrent it will not be triggered in this case.

This does not sound like the behaviour one would be shooting for so perhaps it is a bug?

[eldonmcguinness]

Well it looks like the backup tracker is simply never consulted, since the initial tracker did indeed respond with an error. I say this as a torrent that hits this issue will have both trackers listed in the trackers section with backup tracker only showing "Tracker will be used as a backup" while the other tracker that has errored out will show the error. The proper thing to do would be to contact the backup tracker if there is an error, but that just does not seem to happen in this case; OR, if it is happening, the error message is not being committed to the error field in the RPC call.

I have gotten around this by stripping all but the primary tracker from torrents that I load, while it does result in the expected behaviour it does mean that I don't have the tracker redundancy.

Cheers for the app, I have been using it for years and simply love it!

[eldonmcguinness]

"Tracker will be used as a backup"

Isn't this only used when both trackers are the same, but one is udp and one is http? If that is the case, then the error likely would apply to both. Normally, I only see one tracker per tier.

I don't think this is the case, the torrents in question have normally 2 trackers in the list, one active and the other a backup, however, they resolve to different IPs. Now this is not to say that ultimately this is not the same tracker with yet another interface, but in either case, if transmission is not going to consult the backup tracker when there is an error with the primary, then should not the error field in the RPC results reflect the error message?

I guess that is the real issue I am experiencing, the reported error from the primary tracker never gets populated to the RPC error property for the torrent, instead that field just stays empty when you get the RPC response.

What is the proper process for transmission to utilize the backup trackers? Perhaps if I have better understanding of when the backup tracker is to be consulted I can articulate the question/issue better. I would think the backup would be used anytime the primary returns an error or is unreachable and if the primary is the only tried tracker in a primary/backup setup should not the error field be populated?

Just to be clear, I am not using the transmission web interface to see these messages, I am calling the RPC server to get access to torrent data and parsing it with a stand alone application. The application catches error codes just fine in all the other cases/errors that I have seen, except in this primary/backup setup. In that case it just comes back with a blank error field, as if there was no error.

[eldonmcguinness]

Here's some slightly out-of-date, but still enlightening, info.
viewtopic.php?f=1&t=6684

Thanks for the link, indeed a good read, too bad the multitracker-spec.txt file is not readily available on the bittornado site (http://archive.today/KXDbA). By reading this, in the primary/backup format, the primary server is communicated with first on every attempt and only if the server does not respond does it go on to the next tracker. Kinda how I figured it was happening.

if the primary is the only tried tracker in a primary/backup setup should not the error field be populated?

There is no error, because the tracker is inactive. The primary tracker in the tier was responsive. I assume that if the primary tracker had been unresponsive, then it would have become the back-up, and the secondary tracker in the tier then would be tried.

Right, the primary tracker was responsive but it was replying with an error. The error the primary tracker is giving in transmission is "Torrent Unregistered", which is fine and expected, however, when you pull the RPC data, at least to what I have seen, the error field in the torrent data does not show an error. I'll re-enable the usage of backup trackers and wait till I see the issue again so I can give you more info.

[eldonmcguinness]

Well that did not take long

Here is an example of what I see using the transmission-remote (cli version) application. [transmission-remote -t HASH_HERE -i]

This is a torrent where the tracker has thrown the unregistered torrent error and has a backup tracker; You can see that there is not a "Tracker gave an error" field.

TRANSFER
State: Idle
Location: /home/myuser/files/finished
Percent Done: 0.0%
ETA: 0 seconds (0 seconds)
Download Speed: 0 kB/s
Upload Speed: 0 kB/s
Have: None (None verified)
Availability: 0.0%
Total size: 1.16 GB (1.16 GB wanted)
Downloaded: None
Uploaded: None
Ratio: None
Corrupt DL: None
Peers: connected to 0, uploading to 0, downloading from 0

It is important to note that it does show if you use the [transmission-remote -t HASH_HERE -it], but that would require double the calls to the RPC server, unless I am missing something. I am gonna take a look at the RPC docs later to day to make sure I am not.

This is a torrent that also has an error, but does not have a backup tracker; you can see that the "Tracker gave an error" field is populated.

TRANSFER
State: Idle
Location: /home/myuser/files/finished
Percent Done: 100%
ETA: 0 seconds (0 seconds)
Download Speed: 0 kB/s
Upload Speed: 0 kB/s
Have: 321.5 MB (321.5 MB verified)
Availability: 100%
Total size: 321.5 MB (321.5 MB wanted)
Downloaded: 321.5 MB
Uploaded: None
Ratio: 0.0
Corrupt DL: None
Tracker gave an error: Tracker gave HTTP response code 414 (Request-URI Too Long)
Peers: connected to 0, uploading to 0, downloading from 0

This is the issue that I was speaking of, while I am not using the transmission-remote client in my application to make these calls, I am seeing the same results.

[eldonmcguinness]

Have you tried transmission-remote -i torrent_hash?

-i --info id | torrent-hash
Show details of the current torrent(s)

http://linux.die.net/man/1/transmission-remote

Perhaps I am missing something, but without the "-t" option you will only get an error "No torrent specified! Please use the -t option first."

if you meant was I using "transmission-remote -t HASH_HERE -i" then yes I tried that as outlined in my last post. When using the "-i" option you do not see the tracker error, but if you use the "-it" option you do.

[eldonmcguinness]

Thanks mate, I'll go ahead and file a ticket, I just wanted to make sure I was not goofing something in the handmade RPC call before I did that.