Sonarr version (exact version): 2.0.0.4240
Mono version (if Sonarr is not running on Windows): 4.4.0
OS: custom linux (ASUSTOR NAS)
((Debug logs)) (posted to hastebin or similar): http://hastebin.com/daxowinoxu.tex
Description of issue: Sonarr fails to detect status of downloads queued in transmission (even though it is completed it shows up as in progress). The problem correlates with the presence of exception stack traces in the log (see excerpt on hastebin above). Transmission version is 2.92 (14714), built from sources. The same was happening with version 2.82 originally bundled with the system. Exception is 100% repeatable, no matter if running mono-boehm or mono-sgen.
Seeing the very same, with the very same versions, only as of a few hours back.
Looks like this might be an issue with mono 4.4.1, seeing the same report for another project:
I was having the same issue when using mono 4.2.2 bundled with my NAS, that’s why I switched to mono 4.4.0, but without success.
I am using: 4.4.0 (tarball Sun Apr 17 20:47:21 CEST 2016)
Is it only when connecting to Transmission or does it happen with other download clients and indexers?
Looking into it further, it was ‘as usual’, not a SOnarr issue per se, but Mono.
If only you didn’t have that dependency.
I think it’s something to do with timing at startup.
I haven’t check with other clients as I don’t have them installed but I will create test setup of deluge during the weekend if that’s any help. Unfortunately using another downloader isn’t long-term solution for me as only transmission is integrating nicely with all the other apps I’m using.
Understandable, mostly looking to see if its somehow our Transmission integration or an issue with something broader. I suspect mono is the root cause as that version of Transmission is working for others.
@jun6lee can you elaborate what the solution/workaround for you was?
I found eventually in my case that indexers also weren’t being accessed and the stability was just beyond use, a restart of the NAS has worked for now, been almost 24 hours.
fingers-crossed
What sorry of logging is preferred should you want to have a look, I’ve left it at default but don’t mind changing it for if it happens again.
((Trace logging)) will give us the most detail (though its also the most chatty).
I haven’t been able to test it with deluge, as it has some deps which require much work to satisfy on my NAS. However, I reverted mono to 4.2.4 and I confirm the same exact issue is happening, so it’s not only limited to mono 4.4. I’ll enable trace logging and send additional logs.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.