Opened 7 years ago
Last modified 7 years ago
#5775 new Bug
Error messages generated by torrents with backup trackers are suppressed
Reported by: | eldonmcguinness | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | None Set |
Component: | Transmission | Version: | 2.84 |
Severity: | Normal | Keywords: | tracker errors |
Cc: | thomas_reardon@… |
Description
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. :/