Updated to 2.0.0.811 last night on my Linux server, and started getting some errors.
“Connection to backend lost, attempting to reconnect” (page eventually fades dark, and have to click the “Reload” button that appears.)
“An error occurred performing a WebClient request.”
"[GET] Unauthorized : /log/nzbdrone.txt" (Think this just occurs when I go to the Logs > Files page.)
The connection to backend lost is supposed to handle the scenario where the client loses connectivity to the server for an extended period of time, which would cause UI functionality to stop working. The error messages show issues communicating with Nzbget. Are there any errors in your logs regarding signalR? What version of mono are you running? (mono -V from shell).
The unauthorized error does appear to come from trying to go the the log files in the UI, which could happen if Drone didn’t have access to the file, but its able to write fine. Probably the best thing to do is clear the logs and try going to the log file again and then submit the entire log file.
By “non-local content”, I mean “ignore me, its morning”
I was thinking that series searching for new series that aren’t already on the local system wasn’t working, but I was just using the wrong search bar. So please ignore that. But I am having the same error as the others.
I doubt it… but does nzbdrone have any dependence on the package “shim-signed” at all? I noticed when I updated Ubuntu (which is when this problem happened for me), there were two packages: nzbdrone and shim-signed. shim-signed failed the update (a bug that Ubuntu is aware of).
Not sure what is causing the issue right now, but I know what was changed which affects the UI from essentially timing out. I’ve reverted the UI change and will publish a new build, 2.0.0.813 or higher.
@markus101 said:
The connection to backend lost is supposed to handle the scenario where the client loses connectivity to the server for an extended period of time, which would cause UI functionality to stop working. The error messages show issues communicating with Nzbget. Are there any errors in your logs regarding signalR? What version of mono are you running? (mono -V from shell).
The unauthorized error does appear to come from trying to go the the log files in the UI, which could happen if Drone didn’t have access to the file, but its able to write fine. Probably the best thing to do is clear the logs and try going to the log file again and then submit the entire log file.
Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-5ubuntu2)
Nope, I’m not getting any signalR errors in my logs.
I cleared the logs and went back, and the error still showed, but no mention in the logs. Just the DiskScanService lines. It’s in Debug logging though. Should I change to Trace?
Edit: I am getting this error continuously in NZBGet that I haven’t been able to figure out where it was coming from: “Invalid-request: content length is 0” Doesn’t look like it’s from nzbdrone, but not sure. No other info on it in its logs either. Everything seems to be working fine though. All files being sent.
@Sek0n should be fine at debug, trying to get a quick build out to prevent the UI from timing out, but a 3rd party service we use is failing right now.
@markus101 Currently on 12.0-testing-r906. Maybe it was something that has changed from the stable 11.0 to 12? I just switched to nzbget, and went straight to the testing version. lol
@tymanthius I think the “connection to backend lost” (which everyone here seems to get) is a different issue from what the errors in my logs are, and is what he’s talking about there.
Sounds like he already knows what the backend issue is.
Alright, one of the 3rd party libraries we use for drone (in this case the webserver) was updated, which caused the connectivity to the server to fail immediately upon start, it was immediately noticeable because of the changes made to alert when connectivity was lost.
We have reverted the library and its working again, we have also added tests to ensure it doesn’t fail in this way again. We’ll be re-adding the connectivity check, because the UI is quire reliant on the server being there, but the expectation is this won’t happen in the same way again.
