Sonarr: Option to disable periodic disk rescan

[markus101]

This would make a small subset of users happy, without a significant impact to Sonarr in most cases, but would involve an extra option to skip rescanning disks after an automatic series refresh, but would still be run if Update Library was manually run (this would eliminate the case where someone ran it manually and the files weren't rescanned).

Related forum thread: https://forums.sonarr.tv/t/update-library-function-question/13058

I'd suggest labeling the option Disable periodic series folder rescanning (or something similar) so it's more clear that it's only the periodic ones (though people won't read it anyways).

The pros of doing this would let the people that get worried about their disks actually running wouldn't be affected by the 12 hour rescan and would handle the unionfs case.
The cons would be the people that don't read will toggle it off and Sonarr will never see that the files were deleted, but we'll have logs for that and they'll survive.

Overall I don't see this being a bit negative and we'll still keep the series information up to date so the impact should be fairly low.

[brimur]

I would love this option. Once a month disk scan would be fine. I have Sonarr running on a vps using Cloud storage and the disk scan eats massively into my monthly bandwidth allowance

[brimur]

In the meantime is there a file I can manually edit to set this task to scan the disk once a month? Thanks

[Taloth]

It shouldn't use that much bandwidth, might be worth enabling Trace level logging and see what it's doing.

[brimur]

Maybe I am wrong but it seems to touch each file which with my cloud setup means downloading the file locally first so it can touch it.

Even if there is a sqlite query to change the time that would be great

[Taloth]

It only gets directory listings (basically just ls or dir), that shouldn't get any file contents. (Unless the Cloud API is absolutely horrible).
For any file that it doesn't yet have mediainfo it will try to get the mediainfo but that's just a one time deal.

You'll need some log files to get an idea of what's really happening.

[brimur]

Ok thanks

[brimur]

Just wanted to update this. The refresh series just kicked off and has been going for over an hour. I have been watching the link to the cloud storage and it is most def not just doing a ls or a dir.

http://i.imgur.com/4Y4Vp92.png

I also found this article from a year ago tha @markus101 commented on where a low powered NAS was taking hours to do a refresh. Even the lowest powered NAS in the world would not take hours to do a ls or dir on its local drives.

https://www.reddit.com/r/usenet/comments/39mmdv/sonarr_question_task_refresh_series/

I can only guess the the series refresh involves checking to make sure the media is the same quality as is in the database meaning it has to read the file. This is fine when the media is local but not over a metered connection.

This will be an issue in the not too distant future now that more and more people are using cloud storage with Plex and VPS'

[markus101]

I can only guess the the series refresh involves checking to make sure the media is the same quality as is in the database meaning it has to read the file. This is fine when the media is local but not over a metered connection.

As @Taloth said it doesn't, it just checks which files are there. It only involves getting the list of files in the series directory and it's sub directories and comparing that path to the one stored to make sure it is there.

The only time it would rescan files if it needed to reprocess media info for some reason (you can disable file analysis in settings), but we've only done that one since the initial implementation of that, which was several months ago.

Debug logs (or even trace logs for more detail) would still be helpful to diagnose further (and will show what Sonarr is doing). Without logs we're not going to get anywhere, we need those logs.

[lucacri]

+1 for this. I am using a cloud provider to store the tv shows (encfs + ACD), and a UnionFS folder to combine the local copies to the cloud ones. I started deleting the old copies from my local (keeping the cloud versions alive), and now Sonarr is crawling because it keeps on checking the cloud folder.

Please let us disable the disk check, or at least change the interval from 12 hours to user_defined

[ryanmurray]

+1 this shouldnt be hard to implement

[jul1792]

I'd love this function! I'd love to have my NAS (QNAP 431) always running, but with Sonarr always accessing it, the harddrives won't go into sleep mode. That's why I only turn my NAS on, when I want to watch something. Then Sonarr (on a Raspbberry Pi 3) moves all the new episodes to my NAS.

Please add this function!

[M0UL]

@jul1792 it wont solve that, the diskscan runs only every 12 hours.

[distinguished-git]

Please implement this feature! Google Drive FIle Stream has API limits, and those with large libraries need to be able to control how often they're hitting Google's servers.

[Tybio]

The only content added to my system is via Sonarr, so having a scan every 12 hours and waking all my disks is a real pain. It would be nice to be able to have this run once a week or a month just to keep things clean. No need to "catch" changes if all the changes are via Sonarr anyway!

[karbowiak]

A Temporary fix that is undone as soon as Sonarr restarts:

1. go to config dir where nzbdrone.db is
2. open with sqlite3 nzbdrone.db
3. type: UPDATE ScheduledTasks SET Interval = 0 WHERE TypeName = "NzbDrone.Core.Tv.Commands.RefreshSeriesCommand";
4. type: SELECT * FROM ScheduledTasks; it should now show 6|NzbDrone.Core.Tv.Commands.RefreshSeriesCommand|0|SOMEDATE

And voila, it won't do any refresh series commands until Sonarr is restarted.
Dirty way of automating it, is just running the query every minute with crontab.

/usr/bin/sqlite3 /etc/sonarr/nzbdrone.db 'UPDATE ScheduledTasks SET Interval = 0 WHERE TypeName = "NzbDrone.Core.Tv.Commands.RefreshSeriesCommand"'

[markus101]

Really dirty considering that will also disable any metadata updates from TheTVDB.

[karbowiak]

@markus101 - indeed, but beats having Sonarr crash itself after 36 hours of trying to read everything from GDrive via rclone :)

[distinguished-git]

A Temporary fix that is undone as soon as Sonarr restarts:

1. go to config dir where nzbdrone.db is
2. open with sqlite3 nzbdrone.db
3. type: UPDATE ScheduledTasks SET Interval = 0 WHERE TypeName = "NzbDrone.Core.Tv.Commands.RefreshSeriesCommand";
4. type: SELECT * FROM ScheduledTasks; it should now show 6|NzbDrone.Core.Tv.Commands.RefreshSeriesCommand|0|SOMEDATE

And voila, it won't do any refresh series commands until Sonarr is restarted.
Dirty way of automating it, is just running the query every minute with crontab.

/usr/bin/sqlite3 /etc/sonarr/nzbdrone.db 'UPDATE ScheduledTasks SET Interval = 0 WHERE TypeName = "NzbDrone.Core.Tv.Commands.RefreshSeriesCommand"'

My solution is to add a trigger to the sqlite database. We tell it to ignore any updates to the Interval column in ScheduledTasks. Set the RefreshSeriesCommand interval to whatever you want, and then:

CREATE TRIGGER ImmutableInterval
        BEFORE UPDATE OF Interval
            ON ScheduledTasks
      FOR EACH ROW
BEGIN
    SELECT RAISE(IGNORE);
END;

[markus101]

Done in the v3 work.

[pimlie]

@markus101 Do I understand correct that with these changes you either rescan every 12hrs, never or only after a manual refresh? In the past you spoke about making it possible to adjust the Task intervals (eg set the 12hrs to something differently), did you step away from that solution or is that still on the table as well?

[markus101]

Do I understand correct that with these changes you either rescan every 12hrs, never or only after a manual refresh?

Correct.

In the past you spoke about making it possible to adjust the Task intervals (eg set the 12hrs to something differently), did you step away from that solution or is that still on the table as well?

I don't recall ever saying that for the fact that would also disrupt disk refreshing of series information. That's not on the table and wasn't intended to be.

[Taloth]

Tbh, this is really a stopgap measure for the scenario where ppl don't want to resolve the underlying IO/filesystem issues. It's not intended to be used, it should have a big fat 'darwin warranty seal' you have to break to flip that switch.

[Tybio]

Not sure why this is a silly request, spinning up disks on a NAS every 12 hours to refresh information that is only updated by Sonarr its self isn't the most brilliant solution. One might say that having a configurable refresh time is a very basic function, not the height of stupid to ask for. When you have over 23k episodes, you can't expect the file system to be cached at all times on a system with another 50+k non-sonarr files.

[pimlie]

@markus101 Thanks for your answer and sorry for the confusion about the intervals. From the source code I couldnt determine if the new setting would be a global setting or a setting per series? Or can we bind the setting to a (cold storage) disk path?

@Taloth Please see my previous feature request for a reasoning why this is certainly not 'just' a stopgap measure: https://github.com/Sonarr/Sonarr/issues/2161

@Tybio I guess the main issue is that Sonarr is written with new/changing series in mind and is not so much aimed at being a library for old series. I think we can all agree that its not really usefull to scan twice a day for changes in a series from the 1980's, but for a continuing series with daily/weekly new episodes scanning twice a days makes sense

[markus101]

It’s global. If you want to fine tune things at a series or path level you could use the API to scan them at whatever interval you choose.

I think we can all agree that its not really usefull to scan twice a day for changes in a series from the 1980's, but for a continuing series with daily/weekly new episodes scanning twice a days makes sense

Not really any different if Sonarr is managing everything. Metadata for ended shows is only refreshed once a month anyways.

[pimlie]

Thanks for the response. Does that mean that the disks are also only scanned once a month for those shows? Is there maybe some documentation available about how the metadata refreshing, disk scanning and show status are linked together internally (eg I didnt knew the ended shows were only scanned once a month). Maybe even a block diagram of what runs when and why. I checked the wiki but couldnt find something like that

[markus101]

Does that mean that the disks are also only scanned once a month for those shows?

No, that was for refreshing the series/episode information only, the disk scan still executed. My point was if Sonarr is managing all files as was mentioned above it doesn't matter if it's a continuing or ended show, Sonarr knows what changes it made, so never refreshing shouldn't cause any issues.

[mytvpro]

i cant understand the outcome of this discussion. i am also crawling on google drive api with 6000 series and want to disable series refresh or greatly reduce how often this is done. currentlly taking 6 hours to complete and then runs in 6 hours again

[markus101]

currentlly taking 6 hours to complete and then runs in 6 hours again

No it would run again 12 hours after it finished.

In v3 you can disable the rescan after the series is refreshed.

[mytvpro]

In v3 you can disable the rescan after the series is refreshed.

Thanks! I'm Trying to figure out where/how?

[markus101]

Rescan Series Folder after Refresh on Media Management settings (it's an advanced setting).

[mytvpro]

Rescan Series Folder after Refresh on Media Management settings (it's an advanced setting).

I didn't even realize I had them hidden 😆 thank you!

[Taloth]

currently taking 6 hours to complete and then runs in 6 hours again

@mytvpro That means you have a performance problem that you should check out. I know a user with an excess of 18k shows (via rclone) which now scans fast enough.
But you might need Sonarr v3 beta to get the optimal performance.

So to reiterate, if show refreshes take too long, then you have a problem that needs to be solved, rather than a roll of duct tape.

[mytvpro]

Problem was probing files on gdrive. Solved now thanks

[Taloth]

That 18k exposed a problem in the scan logic that in introduced a needless 1.5 second delay which we fixed. Other users had kodi metadata generation enabled (which doesn't work properly on clouddrives).
That's why I was mentioning it.

[gimpyestrada]

@mytvpro would you be willing to share your findings, I'm experiencing the same problems on my gdrive.