We typically see this with magnet’s (and rTorrent being slow to fetch them), haven’t seen many instances of this, but it looks like rTorrent isn’t adding the torrent quickly enough so Sonarr attempts to remove it, which fails because it’s still not there, but it shows up later.
Either Sonarr and rTorrent disagree about the torrent hash (which impossible given what the hash is) or rTorrent is actually taking a while to add it.
Sonarr relies on rTorrent having the torrent there, so it can set the label, priority, directory and finally start it as there is no way to set all that when adding the torrent.
Side note: you should be running mono with the --debug switch so Sonarr has more information in the stack traces.
The following information would also be helpful:
Sonarr version (exact version): Mono version (if Sonarr is not running on Windows): OS: ((Debug logs)): (Make sure debug logging is enabled in settings and post the full log to hastebin/pastebin/dropbox/google drive or something similar, do not post them directly here)
Sorry about the lack of info. I’ve asked my hosts to enable --debug for mono so will come back if this is possible.
In the meantime:
Sonarr Version: 2.0.0.4427
Mono Version: Mono JIT compiler version 4.2.3 (Stable 4.2.3.4/832de4b Wed Mar 16 13:19:08 UTC 2016)
OS: Ubuntu (3.13.0-107-generic)
This only occurs when Sonarr sends and entire series of individual torrents to Rtorrent, so I think its just overloading Rtorrent with too many requests. Do you think adding an option for a 1 second sleep delay per torrent when using Rtorrent may resolve this?
Depends when it starts happening, Sonarr generally adds items sequentially (the logs will confirm the order). Does it start with the first episode, the last or somewhere in the middle?
It seemed to be around the middle, but its difficult to reproduce so I can’t be sure.
I’ve had difficulty getting mono to run with debug as it is running with start-stop-daemon and adding the switch --debug doesn’t seem to work. I’m probably just being ignorant and will figure it out!
@markus101 The RemoveTorrent doesn’t make sense, if rtorrent couldn’t add the torrent, then it won’t be there to remove. It’s not an issue, but it puts the user on the wrong trail with the Warn message.
As for the real issue: We may have to give it a bit more retries, upping it from 2 to 5. Giving it a total of 500ms to add the file.
I looked at the log directory for the first time and found a bunch of rtorrent.log.xxxx files (where xxxx are a bunch of numbers) and tried to locate the one made around the time of the errors in the debug logs i posted above. Unfortunately I then realised that all of these files are 0 bytes for some reason. In my rtorrent.rc I believe I have the correct log lines:
So I am assuming rtorrent is simply not responding to sonarr’s commands in a timely fashion, hence Sonarr bombarding it with the same torrent from different trackers, and thus rtorrent does not log any errors.
Another thing to note is that when this does happen, I see the same torrent from different trackers sitting in RTorrent in a stopped state, and none of them have any labels of tv-sonarr which is what Sonarr is told to label them as.
For now I have switched over to Deluge, but if you want me to switch back to capture more data please let me know and I will happy to oblige.
It’s quite a stretch to get from ‘empty log files’ to the assumption ‘sonarr is bombarding rtorrent’.
The assumption is understandable, but considering the way Sonarr calls the rtorrent api, it’s extremely unlikely.
If the rtorrent api doesn’t respond, then Sonarr would log a http timeout, for example.
In rtorrent the log.add_output "error", "rtorrent.log" should be something like log.add_output "info", "rtorrent.log". (there are several levels: critical error warn notice info debug)
After all, from rtorrent’s perspective it might not be an error at all, simply a delay.
The reason I asked to look in the rtorrent log file is because that might allow you to correlate between the sonarr log files and rtorrent.
As for the missing label etc, that’s coz Sonarr adds those later, it simply doesn’t get around to it.
But you don’t have to investigate further, only if you want confirmation on what’s going on.
Hi @Taloth, sorry for the assumption, and poor choice of words aka bombardment!
Personally I am liking Deluge and its working seemlessly with Sonarr, however if this is something you would like to fix for other users who encounter the issue, then I would be more than happy to switch back to rtorrent after enabling the info logging to rtorrent. After all, Sonarr’s functionality and dev team are so incredible it’s the least I can do (apart from donations, which I do any time I can afford).
However if this is just a niche or edge case, let me know and I’ll continue with Deluge.
Not really an edge-case, just a combination of unpredictable factors.
However, we’ve upped the period (from 200ms to 1s) during which we check whether rtorrent finished adding the torrent. So it’s unlikely that the problem will occur for other users in the future.
