I’ve installed the Sonarr plugin (Version 2.0.0.2722) for FreeNAS and am experiencing issues with the GUI updating. Everything works properly within Sonarr, but requires a refresh of the entire page (not just clicking to another tab then back) to update. This happens for me in both Chrome and FireFox.
For example:
If I click Update Library, the icon will begin to spin and I will get an alert in the lower right-hand corner stating that “[refreshseries] starting”. However, I will never receive another popup stating that the refresh has completed, even though the Logs state so. Additionally, the spinning icon for refresh will continue spinning. This will last until I perform a browser refresh.
Another example would be upon download. If I select Automatic Download for an episode in the Series screen, I will get a spinning wheel, and the icon of the triangle with an exclamation point will remain. If I refresh, I will then see the progress bar of the download, and the Search icon will have returned to normal.
I have rebuilt this machine a few different times in a few different ways, all with the same result. Additionally, if I update Sonarr to version 2.0.0.2850, the issue persists.
At this point I’m not sure what the problem is, or how I can resolve it. Any guidance would be appreciated.
Which version of mono is running?
Is there a firewall that could be blocking connections?
Sonarr uses signalR with long polling (because web sockets aren’t available on all systems with our web server), to send UI notifications to connected browser sessions.
In the developer console of either Chrome or FF the console and network tabs should give some indication if there are any issues connecting to signalR (which runs on /signalr).
The version of mono listed in Sonarr is 3.10.0 (tarball Mon Jan 26 02:53:37 UTC 2015).
This is all within my local network, there aren’t any hardware or software firewalls that I’m aware of. Additionally, the computer I’m accessing Sonarr from is able to use a version installed on a separate Ubuntu VM without issue.
I’m not very familiar with the developer console, but I do see this:
starting signalR
app.js?v=2.0.0.2722:31106 SignalR: [connecting]
app.js?v=2.0.0.2722:67676 starting signalR
app.js?v=2.0.0.2722:8706 GET http://192.168.16.162:15001/signalr/negotiate?_=1424218930937 500 (Internal Server Error)
app.js?v=2.0.0.2722:31106 SignalR: [disconnected]
Looks like signalr is throwing a 500 error. I’m not very good with Linux, though, so I’m unsure of how I might be able to resolve it.
Unfortunately, no. I turned them up to Trace, but I’m not seeing any errors. I received the signalr error when I refreshed the page, not when I performed one of the actions that is timing out. I don’t see any errors in the Sonarr logs when I reproduce either.
I tried enabling Trace logging and recycling the application to see if there are any signalR errors on startup. I only caught one error, that the database was locked, and only one instance of the word “signalR.” I’ve pasted the relevant portion below, emphasis mine.
15-2-18 08:01:33.5|Info|OwinHostController|Listening on the following URLs:
15-2-18 08:01:33.5|Info|OwinHostController| http://*:15001/
15-2-18 08:01:33.7|Debug|OwinAppFactory|Attaching NzbDroneVersionMiddleWare to host 15-2-18 08:01:33.7|Debug|OwinAppFactory|Attaching SignalRMiddleWare to host
15-2-18 08:01:33.7|Debug|OwinAppFactory|Attaching NancyMiddleWare to host
15-2-18 08:01:33.8|Info|NancyBootstrapper|Starting NzbDrone API
15-2-18 08:01:34.1|Trace|EventAggregator|Publishing ApplicationStartedEvent
I’m now experiencing a weird problem where the UI notifications aren’t updating. For example, I’d click the “Clear Logs” button and would see a notifcation “Starting…” and it would not come back, I’d still see the spinning waiting icon going in the button. A complete page reload would fix it.
I’m not sure what would be causing this. Debug is set but see nothing relating to this in particular nzbdrone.txt.
I’m on 2909 develop and mono 3.6 and running sonarr in a docker.
3.10 is a good upgrade regardless, but before you do that, could you check if you have the same issue with Sonarr 2.0.0.2850 (latest master)? We upgraded signalr recently and I want to make sure its not a cause of your issue.
I just updated to 3.10 via the official repo, still on develop and unfortunately problem still exists and I still see the signalr error in the browser dev tools.
For what it is worth, I was able to install a previous version of Sonarr (2.0.0.2663) on a new jail, and still experienced the same Signalr issue. This version also used mono 3.10.0. I don’t know if that helps you determine whether the Signalr update has anything to do with this, but I wanted to share.
I doubt I’ll be able to update to the latest master as suggested, because I lack the knowledge to properly package the update for FreeBSD/FreeNAS. I don’t know when the repository I use will include an update. In the meantime I’m trying to figure out how to get some more logging for mono, but I’m running into a lot of trouble due to my general lack of knowledge.
If I’m able to find anything, I’ll make sure to include it here.
I ran the command that you provided, but was unable to load Sonarr on the modified port that I have it set on. I tried the default port, it loaded, and my configurations were gone. The 500 error for SignalR was also gone, and the updates were working as they should.
I noticed that I was running under root, rather than the media account that is used for running Sonarr as a service. I suspect that’s why my settings were all back at defaults, and also why the SignalR issue had disappeared.
I won’t be able to look at this until after work tomorrow, but when I do I’ll try to figure out where the service definition for Sonarr is. If I can do that, maybe I can alter it to run the logging command you provided when started as a service, which will hopefully tell us what access is being denied to. Either that or figure out some way to run the command you already provided as the media account.
Awesome, thanks for the info. Might be worth checking the permissions on the files as well, perhaps its something simple and Sonarr can’t access the DLL.
It could very well be a permissions problem in my case as well as I’m using docker. Although it has been working fine for quite some time until recent. The sonarr docker runs as root, though all files are owned by root.
I suspect the problem may lie where I map the internal docker directory /root/.config to the host, but I am uncertain.
More importantly, I’m now seeing this error in the js console window: http://i.imgur.com/QGeu7Zf.png , so it may not be a permissions issue in my case.
Should I be exposing any other ports to the docker besides 8989?
The error that you included in your screenshot is the same that I see when I open Chrome’s debugger. It could still be the same thing, though I know nothing of docker.
I was able to modify the “media” account to let me su to it. Unfortunately, while I was able to run the command and see input in the mono_trace.log, Sonarr didn’t properly start and I wasn’t able to actually load the GUI at all. If that log contains the same errors that I see in the console, it is likely buried between others.
I also modified the service definition to include the command. While Sonarr was able to run, and I see that the mono_trace file is generated, it is empty. I suspect this is something I’m doing wrong with inserting the trace and debug commands into the definition.
I’m going to take another look at it tomorrow, not much progress today. If anyone knows where the SignalR DLLs are stored (generally), I can take a look or just (temporarily) grant the folder 777 and see if it resolves the issue. That would at least point to something in that directory needing permission modification.
Someone in another thread I have on this in the FreeNAS forums was able to identify the issue and update a package with a fix, that I have confirmed is working for me.
Basically, what they found is this:
I found the issue, mono/Sonarr wants to create /.config/.mono/keypairs/some-long-filename.xml
I think this wants to be in the ‘media’ user’s home directory, but ‘media’ doesn’t have a real home.
And:
I found a clean solution, setting the XDG_CONFIG_HOME environmental variable to somewhere ‘media’ can write.