Sonarr version (exact version): 2.0.0.4562 Mono version (if Sonarr is not running on Windows): N/A OS: Windows 10 ((Debug logs)): https://hastebin.com/umolapaqah.tex Description of issue: nzbdrone.exe process keeps terminating
I’m running nzbdrone as an app not a service, and it has recently started abending. Seems to have been getting worse and now won’t stay running for more than a few minutes. Have tried re-installing over the top, but I don’t want to completely uninstall and reinstall and so lose all my series settings.
The activity queue also seems to be getting in a mess - multiple entries for the same item keep appearing and Sonarr is sending repeated items to Nzbget for the same show/episode. I don’t know if this is a symptom of the crashes or if it could be related to the cause of them.
Nothing in the debug log is leaping out at me but I don’t really know what to look for. Would really appreciate some pointers on what to look for. Or a way to start fresh but keep details on which series/seasons to monitor and which profiles to use for them etc.
Your logs don’t show Sonarr starting, let alone crashing. What do the logs show when it crashes? (Hint: check the logs before you start it up again).
Again nothing in the logs with Sonarr sending anything to NZBGet, Sonarr is only going to send multiple releases if NZBGet says it wasn’t added or fails to respond at all (timeout after 30 seconds).
Thanks for the quick reply, and apologies - not sure what I did but must have copied the wrong log file. I was assuming Sonarr created a new log file when it starts so just grabbed the non-numbered one.
In messing about with my PC later this afternoon I foolishly managed to delete a bunch of log files instead of moving them, the next time it happens I’ll upload but it’s been okay for the last few minutes. A look through the log files did show a few oddities - one show’s folder had been dropped inside another’s, so series A was nested inside series B. I corrected that - not sure if it could have caused issues.
I copied the db and config.xml, uninstalled and reinstalled, then followed the process in the wiki to restore the db and config. Started NzbDrone.exe and it fell over, started it again and it did the same. I’d be really grateful if you could check the logs for me again, hope I’ve done it correctly this time.
I don’t see any issues in the logs, but the debug log doesn’t cover the same time range and since it’s more detailed I’d expect it to cover the same thing + the debug messages.
The last line in the debug files is from 17-2-6 07:17:22.8 vs 17-2-6 07:18:54.5 for the info file.
17-2-6 07:18:54.5|Info|DiskScanService|Completed scanning disk for Colony
Does it always fail when rescanning the disk?
Thanks. Just got home from work and had a more thorough look at the logs (I just grabbed them quickly this morning) and noticed the same odd difference in the time ranges. So I checked and the logging level was set to info instead of debug - not sure how that got changed, can’t imagine why I would have done that this morning, but it’s hard to imagine that it did it on its own, so it probably was something I did! Perhaps I shouldn’t have tried to grab some logs in a rush before I went to work, I can’t help feeling I keep wasting your time with incomplete logs, sorry.
Yes, it always fails when scanning the disk - not always on the same series though. Both times that I started the process this morning, it simultaneously did an RSS sync and scanned the disk and fell over part way through. There were episodes apparently missing (showing red in Series view filtered to “missing”) that I knew had been downloaded, and as it scanned the disk it was updating the list and series were changing from red to blue. As it was also doing an RSS sync at the same time it was adding items to the queue.
Because it was failing while scanning, I ran a chkdsk on both the relevant volumes but there were no errors reported.
Just started the process again and it has stayed up, I also ran Update Library and it got through the whole scan this time.
I’ll monitor and try to only report back with decent logs if anything happens again. Thanks for your patience and apologies again - I work in IT so should have done a better job reporting this!
24 hours on and still okay, when it could sometimes fail after just a few minutes previously. As well as running a chkdsk, which didn’t show any errors, I did also do a bit of housekeeping on watched series last night, so possibly a dodgy file has been deleted. There was also a file that was already in a season folder but didn’t show in the season list or get picked up by a fresh scan. I was going to redownload a fresh copy but tried a manual import first and that worked, and it’s listed against the series now.
So one way or another, I’m guessing something related to the filesystem or an individual file was causing it.
Still, a bit of mystery, really. If anything happens again I’ll try to be a bit more rigorous in collecting logs, and at least I have a better understanding of the logs and system generally now.
The sonarr.debug.5.txt log files shows an entry
17-2-9 13:12:35.7
followed by
17-2-11 21:52:41.7
So these are concurrent - the debug file shows entries for several minutes after the main log file, but it seems possible to me that the debug file would capture activity not recorded in the main log, and both start again at approx the same time when I started the process manually.
Then if fell over again at 17-2-11 21:53:37.6 - this is the last entry in sonarr.0.txt.
sonarr.txt is at https://1drv.ms/t/s!AhAUIJstqPm_0X6UJniC35aV1l_s
It starts at 17-2-11 22:18:09.1 when I started nzbdone.exe again manually and you can see that the process starting is the first entry in this log. The sonarr.debug.5.txt log file seems to confirm this as it shows an entry at 17-2-11 22:18:10.0.
What puzzles me is that sonarr.0.txt is exactly 1000KB in size, as if the process ended at exactly the point it would roll over to a new log file.
Hopefully both files show enough info to point at what has caused it to fail. I really hope I’ve captured all the relevant information this time. If you could take another look I’d be extremely grateful.
The files roll over at 1MB, the latest file would be sonarr.txt, sonarr.0.txt is the next file, all the way up to 5 or 50 (5 for info, 50 for debug/trace).
17-2-9 13:12:35.7|Debug|VideoFileInfoReader|Getting media info from C:\ProgramData\NZBGet\complete\TV\The.100.S04E02.1080p.WEB-DL.DD5.1.H264-RARBG\The.100.S04E02.1080p.WEB-DL.DD5.1.H264-RARBG\The.100.S04E02.1080p.WEB-DL.DD5.1.H264-RARBG.mkv
That’s Sonarr getting the media info for the file from MediaInfo and it’s likely crashing and taking down Sonarr. The unfortunate part is something might have been logged, but wasn’t written the the log file because Sonarr was taken out before it could write anything.
Looks like there is a recent update to media info, currently using 0.7.91.0, but 0.7.92.1 is available and likely addresses some issues, we’ll get it updated and hopefully that takes care of it.
Thanks for such a quick reply. My point about the 1MB log file size was that the process seemed to terminate exactly as the log file rolled over - the first entry in the new log file is the process starting, which made me wonder if the process possibly terminated as part of creating the new log file and renaming the old one. However it didn’t do that the previous time so I guess it’s not significant, just coincidental.
Anyway, thanks for the response, I’ll keep an eye on updates and see how things go with a newer mediainfo.
Quick update - process was failing again this morning even after the update to mediainfo. Watching the NZBGet queues it seemed at first that the handover from NZBGet to Sonarr would cause the nzbdrone.exe to fall over. I use Clinton Hall’s nzbtonzbdrone script with minimal options, just to check the file isn’t corrupted before handing it to Sonarr, no transcoding etc. is enabled. It’s been working fine for ages but I’m trying to pin down anything non-standard. Checking the script’s logs alongside the sonarr.debug.txt it looks as if the script is working, and Sonarr does receive the file, but it fails on VideoFileInfoReader getting media info as before.
However I’ve been going through my setup and have removed a post-processing script in NZBget that runs mkclean against downloaded files to ensure they’re optimised for streaming. Mkclean is from matroska.org, but it hasn’t been updated since 2012, and I thought it was worth removing anything that modifies the files to see if that is causing an issue with mediainfo.
If it still fails I’ll remove nzbtonzbdrone entirely just to try and rule that in or out.
Went through the logs and found that on several occasions it failed when scanning a particular series that had its episode files split between two season folders, one named “Season 1” and another named “Season 1 (2015)”. Moved all of the files out of the second folder into the first and Sonarr has stayed up since. Not sure if that could be the cause or just another coincidence; there are other series set up like this, the second naming scheme was from when I was using Filebot to rename, but they’ve been that way for a while.
Not sure how relevant this is but thought it was worth reporting.