Sonarr downloading unmonitored episodes

[regregoryallen]

Hello Sonarr experts!

I’m having a very strange issue that I cannot seem to track down. I’m starting to believe it may be a bug. In fact, there are multiple issues, but I am focusing on one initially, hoping that the root cause is behind the others. I have searched for similar issues in the forums and all I find are things from a year or more back that seemed to have been resolved.

Simply put, sonarr is requesting download of episodes that are not monitored. What’s more, it is sending downloads requests (in this case, a torrent) to a disabled client.

First, some preliminaries.
Version 2.0.0.3732 (from Jan 15th)

Software/hardware stack:

• Sonarr on Windows PC (10.11.12.30)
• NZBGet on raspberry pi (10.11.12.25)
• Transmission on same raspberry pi (10.11.12.25)
• Kodi on a different raspberry pi (10.11.12.26)

Here are two specific examples:

================== Example 1========================
Late Show with Colbert: Seasons and episodes all show unmonitored.

However, episode #89 above was sent to Transmission

but is NOT in my wanted queue.

And the weirdest part – Transmission is defined, but disabled, in my download client set up:

Plus I have turned off RSS and search for Kickass, the only torrent source I have.

============ Example 2 =============

Black Sails:

This one is slightly different, in that the Series is unmonitored, but the episode shows “greyed” monitored – and this one was sent to NZBGet to download (it failed, but the history is there).

The record in NZBget:

===================================

I have several more examples of completely unmonitored episodes showing up in Transmission. FYI, I have examined the database to be sure that the UI was telling me the truth with respect to Transmission and Kickass configuration:

SQL: select ID, Name, EnableRSS, EnableSearch from indexers;

ID|Name |EnableRSS|EnableSearch
–±--------------±--------±-----------
2 |KickassTorrents|0 |0
3 |nzbplanet.net |1 |1
4 |OZnzb.com |1 |1
5 |NZBndx |1 |1

And likewise for the monitored status of the series and episodes:

SQL:
select S.ID, S.Title, S.Status, S.Monitored, S.AddOptions, E.ID, E.title, E.monitored
from Series as S, Episodes as E
where S.id = E.SeriesID
and S.ID in (7, 19)
and E.id in (3997, 7943)
;

I enabled Trace logging and did a series Update. I found nothing related to those episodes or any others that were not already on the disk (lots of parsing messages at Debug level and some regex stuff at Trace level). I’m not sure it’s helpful, but I’ve pasted the log from that exercise at http://pastebin.com/L3d34a0t (expires Feb 24).

I sure hope I’m missing something and someone can point out the error of my ways. And if not, then I hope I’ve provided enough detail to lead to a resolution.

Let me know if there is anything else I can provide, and thanks in advance.
–Roger

[markus101]

What does Sonarr’s history show for these episodes?
Unless there are multiple bugs in play here, that we’ve never seen before:

• communicating with a a disabled download client
• using RSS when RSS is disabled
• ignoring monitored states for both series and episodes

I’m inclined to believe these results are coming from something other than Sonarr. We’ll need debug logs showing the item being send from Sonarr to Transmission to investigate further.

[regregoryallen]

Well, I guess that at least confirms that this is a really weird issue

FWIW - the history on each of the examples is completely empty.

Note, this is a fairly new configuration - About Dec 1st, I moved everything from a PC-based/Sickrage system to the current arrangement on raspberry pi’s with sonarr, and I’ve completely disabled (as in shut down the server) the old configuration, and further, there is no other software that even “knows” about the instance of the Transmission on the r-pi.

I also felt like there was no way Transmission could be getting anything from Sonarr given that everything was disabled… obviously, I have not gone as far as shutting down the Transmission service, since that would kinda defeat the purpose of trying to get this working correctly.

I have thus far not been able to catch it in the act of sending the torrent to Transmission. Do you have any suggestions on how to capture that event?

I’m tempted to rebuild and try to strip things down and reproduce this in a more controlled environment, but I’m concerned that I’d eliminate whatever interaction is eliciting the behavior.

Let me know if you have other troubleshooting suggestions.

–Roger

[Taloth]

If it isn’t in History, then sonarr didn’t grab it. you can check the logs.db and log files if you want as second check.

If you want to be absolutely sure, enable Debug level logging. That will output this line, which absolutely logs every single api call to Transmission.
At Debug level the log file will last several days iirc, so have at it

[regregoryallen]

OK - I’m cleaning out all existing torrents and NZBs (which, BTW, is a lot, from episodes years old and already downloaded, as well as new stuff that is not monitored). I’ll unmonitor EVERYTHING, set debug on and let it run for awhile. I’ll post results as soon as I can.

[Taloth]

Just to point out, from our perspective this is next to impossible. Either it’s some other script, rss feed, someone accessing the network, or just gremlins.
As mentioned by markus, there would have to be like 4 separate bugs, each of monumental scale, to make it remotely possible. He also suggested simply turning off Sonarr for a while, see what happens.

But time will tell.

/me grabs some popcorn.

[regregoryallen]

Gremlins!

I disabled Sonarr completely, and Transmission still starts torrents. It would seem it’s not Sonarr, but something else is “magically” starting torrent files in Transmission.

I’ve gone through several iterations of trying to capture exactly how and by whom these torrents are starting, but have not been successful. My last round of testing involved changing Transmission’s rpc-whitelist and/or the username, and any change there does seem to stop the torrents re-launching.

All of this points at something else on my netowrk submitting the torrents to Transmission, but I am quite certain that is not the case. Without going into painstaking detail, there simply is no other machine that has that access and information. I’m left with a mystery, but I’m out of patience to solve it. My “solution” is to disable Transmission completely for now. I might try testing it again with changed credentials at some later point.

Sorry for the wild goose chase. I really had hoped I would find a root cause in case this ever happened to anyone else, but that doesn’t seem to be in the cards.

–Roger

[Taloth]

BEST. SHOW. EVER.

(Tnx for letting us know)

Considered capturing tcp traffic using wireshark or tcpdump? Might give you a hint of where it’s coming from. even with transmission disabled you should see connection attempts on the port.