Error messages generated by torrents with backup trackers are suppressed

[eldonmcguinness]

I wrote a small application to interface with transmission's RPC service and have run into a small issue.

When a torrent has a single tracker tier with a backup in said tier, if there is a tracker error it is not populated in the error or errorString fields of the RPC response.

This can also be seen when using transmission-remote:

This is a torrent where the tracker has thrown an "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.

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

In the mean time, I can bypass the issue by removing all but one tracker from the offending torrent and then the RPC calls and transmission-remote both show the error as expected. This however cuts out the redundancy of backup trackers. :/