Sonarr version (exact version): 2.0.0.4613
Mono version (if Sonarr is not running on Windows): latest release
OS: OSX 10.12.3
Hi,
Not sure what logs to provide exactly, but after updating Sonarr to the latest release last night, CPU usage on my MacBook Air runs through the roof. Whereas it was rather low before, the Activity Monitor now indicates a usage of over 120% constantly.
Any explanation for this behaviour?
Thanks,
J.
At least one other user had two instances of Sonarr running on his mac. you should check that in Activity Monitor.
well thatās what I did, and it runs at 130%. Question is where this behaviour comes from
So, did you see two mono instances running?
Also, if you want to know about what itās doing, you should check the Sonarr log files.
Hi,
Iām experiencing the same kind of behaviour on my system after the last update, CPU rests at 35%-40% and after a few days hits 99%.
The system is: HP G9 Micro Server with 8GB ram, OS Win10, Sonarr version: 2.0.0.4613
Logs show no errors i can see, no duplicity in the processes.
One other thing I noticed was the āRefresh Seriesā task never completes/ even tho the logs show it has reached the last show its still running.
Both the software and server have been rebooted.
Any ideas?
Regards,
Zoctar
Hi
As an intro I want to say how great Sonarr is, I came across from Sickbeard a few months ago, wish Iād done it way earlier.
Iām getting similar ācpu hoggingā - NzbClone.exe *32 using 100% of one core on my system.
I first noticed this several weeks ago.
Nothing much happening in logs AFAIK:
Although everything seems to be working fine, just my box is sluggish under the permanent load.
I tried restarting (complete reboot) about a week ago, and has been sitting on 50% the whole time since reboot (based on total CPU time used, nzbdrone.exe 159hrs, system idle 141hrs)
cheers
Iād appreciate it to get a full trace level log file from one of you. Hopefully it will shed some light on what itās doing.
Settings->General->loglevel=trace.
Where the log files are: https://github.com/Sonarr/Sonarr/wiki/Log-Files
Probably a good idea to clear the logfiles first, and then zip up everything after a 5-15min run.
While collecting the log files, please make sure Sonarr is indeed at 100% CPU during the period. And please check that the user Sonarr is running under is indeed the home directory youāre gathering the logfiles from.
Feel free to encrypt the logs, if you want, and then PM me a link. Although the logfiles are automatically sanitized of most sensitive info, we canāt guarantee that nothing sensitive remains. So sending it privately is probably the best choice.
I had a similar issue, but I think I managed to find the reason (for me at least).
The notifications which appear in a box in the bottom right of the web interface showed one particular series had the [refreshseries] event running all the time, if i cleared the box it just came back again.
I investigated the series it was stuck on and it turned out one of the videos was corrupt. I was unable to delete the file in question as windows reported it was in use by nzbdrone. Stopping the nzbdrone process allowed the file to be removed and sonarr functioned without the high cpu usage once it was restarted again.
Good afternoon bagpuss
It seems it was the same for me, I have removed the show it was sitting on by stopping Sonarr then moving the files away and then starting Sonarr again.
What is odd id that those files have not been touched in a long time, Iāll check them all to see if any are corrupt.
Good catch mate.
Regards,
Zoctar
@zoctar What is the affected mediafile (releasename and filelength)?
For Win10 Sonarr includes the mediainfo.dll, for osx too, but for linux it uses the distro library.
About a month ago we updated the included mediainfo.dll from 0.7.91 to 0.7.92.1.
The Sonarr trace logfile might show if itās looping internally in mediainfo or whether itās roundtripping in Sonarr.
Sonarr doesnāt actually send the file to mediainfo, it only sends the parts mediainfo requests. which is usually like 1% of the total file. If a new āpartā is sent, Sonarr will log that in trace, thatās what I mean with āroundtripā.
So it would be interesting to see if mediainfo keeps requesting the same part over and over again, or whether itās just in an endless loop internally.
Hi Taloth
Iāve set that logging level, Iāll leave it another 15 mins then send logs thru to you. I can send a screen shot of task manager showing cpu usage.
Hmm, seems the logging level automatically reverts to āinfoā when you leave that settings tab. 2nd tryā¦
I bumped the forum trust level for your accounts, so you can actually send PMs 
Tnx, but thatās just the default info level log and doesnāt contain useful information. See below.
Dāoh. As noted above, I got caught out the first time that I set loglevel=trace, but when I exited that settings page and returned, the level had reverted to āinfoā. I just now worked out you need to hit āsaveā for the setting change to become effective. The āsaveā button is not visible on my screen when Iām scrolled down to see the āloglevelā setting. Just trying to make the case that Iām not a complete idiot.
Also I only cleared ālogsā, not log files. Iām all over it now though
Having another go now. Will post logs in ~15mins.
Thanks for your patience.
[edit] logs sent via pm
Tnx for helping me investigate this.
One more thing: Can you clear the log files (itās in the UI, but you can also just delete the files) and then restart Sonarr?
That way the log files should contain the entire startup sequence at trace level up till the point that RefreshSeries getting stuck. You donāt need to wait more than a couple of minutes before collecting the log files. Once the UI is available again after startup and the CPU load kicks in.
The log does show that RefreshSeries is indeed still running for > 60min, but doesnāt actually progress as far as I can tell.
The log also shows that MediaInfo doesnāt repeatedly requests file data, so thatās not it. But itās still likely itās stuck in mediainfo somewhere. Hopefully the startup sequence log will give more insights.
logs sent.
Wow. Genuine thanks for getting me to give some long-overdue TLC to this PC. I noticed while watching task manager that somehow windows search had become enabled, and was using most of the other core of the cpu. I disabled that, plus deleted the series mentioned in the PM, now all is good. [refreshseries] now runs 10x faster than before AND it runs to completion. CPU use is 0% after scan completes.
Feeling somewhat dim that I didnāt trigger it must always have been displaying the name of the problem series when it was using 100% cpu. Maybe that creates a simply path for a workaround - ugly I know, but if scannign series name stays the same for some timeout period, the process could be jkilled, and that series (or better still a specific file) flagged as corrupt.
I didnāt delete any files, I just deleted that problem series from Sonarrās list. Let me know if you want me to re-add it to help you debug what was going on.
Evidently the file that @effgeeās Sonarr was hanging on was zero length, which MediaInfo really doesnāt like (anymore). Iāve pushed a fix to develop to prevent that from happening.
If other users run into the same problem, but donāt have zero-length files, please I need at the very least the release/file name.
Confirmed that there were 3 series in my collection with 0 length files and was getting 100% cpu usage. Removing the 0 length files fixes this behavior.