Being able to disable tasks or enter a custom interval would be great.
I have tried editing the database file to change the Last Execution as a date far in the future to prevent scans but it eventually reverts back.
The main reason for this is Refresh Series has been going for over 24 hours and has only reached shows beginning with M. The larger someone’s library, the bigger the issue becomes.
We have no plans to allow tasks to be disabled individually.
The Refresh Series task is integral to Sonarr’s operation.
How many series? People with thousands of series don’t take that long to refresh.
Logs should indicate if the issue is getting details from Skyhook (our TVDB proxy) or checking the disk for changes, which only involves getting a list of files unless every file was renamed or removed outside of Sonarr.
You’re going to be best off solving the issue, not trying to work around it. Some additional details on your issue would be useful:
Sonarr version (exact version):
Mono version (if Sonarr is not running on Windows):
OS:
Trace logs:
(Make sure trace logging is enabled in settings and post the full log to hastebin/pastebin/dropbox/google drive or something similar, do not post them directly here. Post in .txt not .doc, .rtf or some other formatted document)
Thanks for the reply.
Sonarr version
2.0.0.5203 - May 10 2018
mono --version
Mono JIT compiler version 5.2.0.215 (tarball Mon Aug 14 15:46:12 UTC 2017)
Copyright © 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: sgen (concurrent by default)
Standard Ubuntu 16.04 install, no dockers.
I have 6,000 series and from what I remember it doesn’t normally take more than a few hours to scan them in usually. For some reason this one has been going on for over 24 hours and still not finished.
It’s making my Sonarr struggle to load any pages although the rest of my server is fine (low disk io etc). I’ve tried restarting Sonarr and editing the database but it just resumes where it left off.
I’ve had a look at some trace logs and I see quite a lot of errors when scanning files for audio tracks from what I can make out.
Here’s the MediaInfo of one of those files
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42 (isom/mp41/avc1)
File size : 47.0 MiB
Duration : 10mn 0s
Overall bit rate mode : Variable
Overall bit rate : 657 Kbps
Encoded date : UTC 2015-08-25 17:37:54
Tagged date : UTC 2015-08-25 17:37:54
Writing library : Apple QuickTime
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Format settings, GOP : M=2, N=50
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 10mn 0s
Source duration : 10mn 0s
Bit rate mode : Variable
Bit rate : 526 Kbps
Maximum bit rate : 555 Kbps
Width : 640 pixels
Height : 360 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.091
Stream size : 37.6 MiB (80%)
Source stream size : 39.8 MiB (85%)
Language : English
Encoded date : UTC 2015-08-25 17:37:54
Tagged date : UTC 2015-08-25 17:37:54
Color range : Limited
mdhd_Duration : 600040
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 10mn 0s
Bit rate mode : Variable
Bit rate : 96.0 Kbps
Maximum bit rate : 101 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Frame rate : 43.066 fps (1024 spf)
Compression mode : Lossy
Stream size : 6.87 MiB (15%)
Language : English
Encoded date : UTC 2015-08-25 17:37:54
Tagged date : UTC 2015-08-25 17:37:54
Other #1
ID : 3
Type : Object description
Format : System Core
Codec ID : 2
Duration : 10mn 0s
Title :
Language : English
Encoded date : UTC 2015-08-25 17:37:54
Tagged date : UTC 2015-08-25 17:37:54
mdhd_Duration : 1000
Other #2
ID : 4
Type : Scene description
Format : System Core
Codec ID : 2
Duration : 10mn 0s
Title :
Language : English
Encoded date : UTC 2015-08-25 17:37:54
Tagged date : UTC 2015-08-25 17:37:54
mdhd_Duration : 1000
I’ll PM you links to the log files, I hope you don’t mind!
Is there an easy way to stop the scan? It’s still going. 
18-5-16 01:08:11.4|Trace|DiskScanService|Import decisions complete for: [85034][Chuggington] [00:07:19.0572979]
Looking at the logs, several files are there that are either duplicates or renamed as Sonarr is trying to read media info and going through the import process, which is taking minutes, likely due to the files being on cloud storage/not on a local disk.
You’ll see a increase in speed scanning existing series folders if you disable Analyse video files on the Media Management settings page, but that’ll mean media info isn’t available for existing files. Files imported by Sonarr will always read media info.
Seeing several of these logged:
18-5-16 01:08:11.4|Debug|ImportDecisionMaker|File rejected for the following reasons: [Permanent] Has the same filesize as existing file
Which are likely duplicates of the same file.
You can restart Sonarr to stop it, but it’ll start up again anyways.
I have had analyse video files turned off for months and can confirm it is still currently turned off.
I am indeed reading files from the cloud - Chuggington files have not been changed in any way since September 2017.
I think the most recent version of Sonarr may have brought these problems on. I am going to change to an earlier version and see if it fixes the problem I am having.
There was a bug where media info for files in the series folder was being read, but that should be fixed in 2.0.0.5203.
Are there duplicate files in there? Based on the logs there is an existing file linked to an episode in Sonarr and another file that is the exact same size, but has a different filename.
Yes there were some dupes, I cleared them out and it has since moved on but still scanning away. I’ll leave it for another night and see how it does. Thanks for your help so far!
After reverting back to the master branch and letting it finish the scan it seems to be working for now. I’m not entirely sure what caused the issue of such long scan times but if it happens again i’ll be sure to look into it!
Thanks again @markus101
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.