Sonarr on Synology: Unable to retrieve queue and history items from nzbget: Cannot access a disposed object. Object name: 'System.Net.Sockets.NetworkStream'

Help & Support
#1

Sonarr version: 2.0.0.5018
Mono version: 4.6.2-0095
OS: Synology DS114 / DSM 6.1.3-15152 Update 5
Nzbget version: 19.1
((Debug logs)): https://pastebin.com/jzC4aDxe
Description of issue:

All programs are running on the same machine.

After a few minutes of running, Sonarr will throw an error along the lines of “all download clients unavailable due to errors.” This is usually coupled with "Unable to retrieve queue and history items from nzbget: Cannot access a disposed object. Object name: ‘System.Net.Sockets.NetworkStream’."
These errors are cleared by manually going in, testing the connection to nzbget and saving. The error(s) will then usually appear again. When an episode is up for a search with the error still present, Sonarr will not grab it or send it to NZBGet.

I’ve tried uninstalling and reinstalling both Sonarr and NZBGet, trying to switch the mono version to the community version (which I can’t get to work as sonarr won’t even start up) and trying with clean configurations. Error still propagates.

It seems there’s no way to manually install the latest Mono build on synology, which is something Id be opening to trying but right now I seem to be stuck. Is there a way to prevent Sonarr from doing some sort of check of NZBGet? At this point it seems like something is broken by default and I haven’t been able to find a reasonable explanation of what the “'System.Net.Sockets.NetworkStream” error means. Though it seems I may not be alone with this error.

I should note that I am also running Radarr and it does not produce this error. It would appear that this is an issue related specifically to Sonarr. This Synology model does not support Docker so I can’t go that route.

#2

It’s appears to be a mono bug which hasn’t been fixed in any released version, not sure if it will be fixed in 5.4.

#3

Wow. That’s a long time for the bug to be there. When’s the last version that didn’t have it? Since I can install older versions I wonder if that will work

#4

4.4. or 4.6 IIRC . It’s sporadic and doesn’t occur on every request, but does seem to affect fetching queue/history from NZBGet when it does occur.

#5

Just to add, I get this error as well on my Synology using both the Sonarr and Mono packages from the SynoCommunity repo (Mono 4.2.6.7-8). It doesn’t seem to affect things too much but I have noticed that sometimes it fails to import a completed download and I have to do it manually, which is a bit of a pain.

Seems like the Mono version on Synology has not been updated for quite some time now.

#6

I seemed to have fixed it by downgrading to mono 4.2.1 using an older package in synology’s arxhives then following the instructions here: https://www.reddit.com/r/sonarr/comments/4c7ddp/howto_sonarr_on_synology_dsm_60_workaround/

I thought I had performed this instruction before but noticed that it was still using the community version of mono. I haven’t had the issue since

#7

Would like to bring this topic up again - as I am having the same problem an a daily basis.

Sonarr version: 2.0.0.5054
Mono version: 4.6.2.7-8 (from SynoCommunity)
OS: Synology DS115j / DSM 6.1.4-15217 Update 1
Nzbget version: 16.4

I am getting the following error message:

Unable to retrieve queue and history items from nzbGet: Cannot access a disposed object.
Object name: ‘System.Net.Sockets.NetworkStream’.

Details:

System.ObjectDisposedException: Cannot access a disposed object.
Object name: ‘System.Net.Sockets.NetworkStream’.
at System.Net.WebConnectionStream.EndWrite (System.IAsyncResult r) [0x000d3] in /spksrc/native/mono/work-native/mono-4.6.2/mcs/class/System/System.Net/WebConnectionStream.cs:616
at System.Net.WebConnectionStream.Write (System.Byte[] buffer, System.Int32 offset, System.Int32 size) [0x00059] in /spksrc/native/mono/work-native/mono-4.6.2/mcs/class/System/System.Net/WebConnectionStream.cs:630
at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x000d2] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Common\Http\Dispatchers\ManagedHttpDispatcher.cs:59
at NzbDrone.Common.Http.Dispatchers.FallbackHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x000b5] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Common\Http\Dispatchers\FallbackHttpDispatcher.cs:53
at NzbDrone.Common.Http.HttpClient.ExecuteRequest (NzbDrone.Common.Http.HttpRequest request) [0x0007e] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Common\Http\HttpClient.cs:119
at NzbDrone.Common.Http.HttpClient.Execute (NzbDrone.Common.Http.HttpRequest request) [0x00000] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Common\Http\HttpClient.cs:55
at NzbDrone.Core.Download.Clients.Nzbget.NzbgetProxy.ProcessRequest[T] (NzbDrone.Core.Download.Clients.Nzbget.NzbgetSettings settings, System.String method, System.Object[] parameters) [0x00047] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Core\Download\Clients\Nzbget\NzbgetProxy.cs:232
at NzbDrone.Core.Download.Clients.Nzbget.NzbgetProxy.GetGlobalStatus (NzbDrone.Core.Download.Clients.Nzbget.NzbgetSettings settings) [0x00000] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Core\Download\Clients\Nzbget\NzbgetProxy.cs:125
at NzbDrone.Core.Download.Clients.Nzbget.Nzbget.GetQueue () [0x00000] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Core\Download\Clients\Nzbget\Nzbget.cs:55
at NzbDrone.Core.Download.Clients.Nzbget.Nzbget.GetItems () [0x00000] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Core\Download\Clients\Nzbget\Nzbget.cs:184
at NzbDrone.Core.Download.TrackedDownloads.DownloadMonitoringService.ProcessClientDownloads (NzbDrone.Core.Download.IDownloadClient downloadClient) [0x0000c] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Core\Download\TrackedDownloads\DownloadMonitoringService.cs:89

As a result new items are not handed over to Nzbget. However if I go into Settings -> Download Client -> Nzbget and click on Test, the test succeeds and the warning message is cleared. However not even 5 mins later the problem is back again.

Would appreciate details on how to solve this :slight_smile:

#8

Does doing what I did in the post above fix it?

#9

I do not know how to manually downgrade Mono. Can you please help with details?

If I install Sonarr through SynoCommunity, it forces me to install Mono from SynoCommunity as well. Even if I already have Mono installed directly from the Synology library

Another question: How did you upgrade Nzbget to 19.1? Did you manually install it on you Synology?

Thanx

#10

You can leave the synocommunity package there. What you want to do is uninstall the official synology package and do a manual install of the old version from here https://archive.synology.com/download/Package/spk/Mono/4.2.1-0089/ get the right package for your DS’s architecture.

After you install that follow the instructions from the Reddit post I linked to redirect sonarr’s startup script to this mono package.

#11

Thanks :+1:

Managed to do both the install of the previous Mono version as well as the edit to the startup script. Have restarted the Synology, so everything should be in effect now

Off to bed now - will write feedback tomorrow if the warning message comes up again or if it is solved

Is the manual install of Nzbget 19.1 worth it in your view?

#12

I think it’s worth it. The synologycommunity package is ancient and doesn’t seem like they plan on updating it soon. With the manual install it also auto updates and you can run the beta branch as well

#13

This seems to have done the trick. Have not had any error messages since making the change.

I guess I will have to play around a bit with Linux and do the manual install of Nzbget

Thanks again for your help !!

#14

It took me quite a while to get Sonarr working correctly after an upgrade went wrong and I had to totally re-install and re-configure, so I’m a bit wary about mucking around with scripts and the like.

Thing is, before the update the error was logged much more frequently but now, although it is less, Sonarr tells me that it has disabled NZBGet because of repeated failures. This seems to mean that some NZBs are not being passed properly to it and just seem to be sitting there. I can then run a test on the client, the error goes away, and the NZB gets passed to NZBGet.

Is there any way to stop it disabling NZBGet? Is this presumably a new thing that has been added to one of the recent updates? It would seem to me that if it is just an occasional bug with mono that all Sonarr needs to do is just keep trying rather than disabling the download client entirely.

#15

There is no way to disable it. It’s all due to the mono issue. I would do what I and wolfandy did and just edit the script, it doesn’t make much sense for sonarr to add a function to ignore what is a failsafe measure. It’s just telling it to use the mono version that works

#16

Yes, I know, I will probably have to bite the bullet and do it (and cross everything while I do!)

Just to confirm then first though, I currently have the Synocommunity version of Mono only - I have not installed either the current Synology version through Package Center or the old Synology version manually yet.

If I now install the correct older version from the link you posted above for my DS213J (which I’m fairly sure is the Armada370 version) using DSM and then browsing to the SPK on my computer, stop Sonnarr and then edit that script and start Sonnarr, this is all I need to do? Having two different versions of Mono running at the same time won’t cause any problems? Or do I need to either stop or uninstall the synocommunity version of Mono at some point?

Thanks.

#17

You shouldn’t need to mess with the community mono package at all. No programs will be using it at this point and since it runs in its own container more or less there’s no conflict anywhere. I suppose you could manually stop it from running.

But yes, all you need to do is stop sonarr, install the old version and edit the script so when sonarr starts it will use the old synology package instead of the community package

1 Like
#19

Crossed my fingers and just made the change. Everything still seems to be working OK, so it’s now wait and see to see if it is a permanent cure - I’ll post back in a few days to confirm, just so other people experiencing the same issue have a bit more feedback.

#20

Hi,
About to install the older version of mono. Appreciate the great info here to get this done and links to what is needed…
I have a ds212j specs show it having Marvell ARM 88F6281, single core, 1.2 GHz.

I would appreciate help in knowing which file to download from the link. I think the arm but if so v5 or v7?

Thank you for help,
Bryan

#21

This page suggests that the package you want is the v5:

https://www.synology.com/en-us/support/download/DS212j#packages

Also, just to say I have had no errors in my logs at all since following the instructions here (it’s only been a day and it’s only had one thing to download, but so far so good).