Every 12 hours when the ‘Refresh Series’ task runs, it seems to update every single .nfo file, even though nothing has changed since 12 hours ago. As my media is stored on a SnapRaid array this is causing huge numbers of files to be reported as updated every time I run sync, causing sync to run longer than needed and potentially affecting my ability to perform a recovery as these NFO files end up being part of the data/parity set needed.
This could be resolved in a variety of ways, with pros and cons to each. The easiest quick-fix would be to simply allow users to disable the ‘Refresh Series’ task completely, while still keeping the ability to do a manual ‘Update series info and scan disk’ on individual shows if required.
Another option would be to simply only create NFO files for episodes that don’t currently have one - this would also resolve the issue of Sonarr overwriting changes to NFO files every 12 hours (eg. watched status always being reset).
The file is only re-written if the data changes, a hash of each file written is stored and when determining if the file should be overwritten that hash is compared with the new hash of the content. Anything changing in the data (ratings, description, etc) would cause it to update, but that typically doesn’t happen after a day or two of the episode airing.
That’s akin to using a sledge hammer to kill a mosquito, assuming you hit it it will work but causes damage.
The reason we didn’t do this was to avoid stale data, nothing like having every episode called TBA because it was imported before the data was updated on TheTVDB. This may very well be what we end up doing to deal with the watched status problem, especially when Kodi’s Episode metadata format is invalid XML when the file contains multiple episodes.
Perhaps then I’ve encountered a bug because it seems to be updating way too many files. A snapraid sync ran over night last night, and this morning snapraid diff is telling me I have 272 updated files again - scrolling through the output they are all NFO files.
But perhaps its a trade-off that some users are willing to make? As a more generic feature request, why can’t end users edit all of the scheduled tasks for custom intervals (and set to 0 would disable).
Right now it seems my only available option to stop all the needless updates is to disable the metadata functions of Sonarr completely. Stale data is better than no data, and its easy enough to fix stale data if I encounter any by just deleting the stale .nfo file and letting Sonarr then rebuild it when it finds it missing. An extra UI element to force a metadata refresh would be easier for lazy users but could be added later as an addtional feature.
272 isn’t that many when you consider there is one for every series and every episode, that doesn’t sound like a bug, just data being updated (likely ratings).
That would also affect getting updated information from TheTVDB, especially important when series are updated the day of the airing.
Cost vs benefit, a few users would find it useful and then there would be way more that changed them blindly and Sonarr essentially stopped working, the tasks are all pretty critical to Sonarr’s operation in one way or another.
Yeah, that would do it.
Lose-lose, some people want it to refresh and others don’t, which makes having it an option, which means you get the people that flip switches and don’t know what it does (and don’t read the help text) and then come asking for help (the number of people that blindly enabled metadata file creation without understanding it was surprising. Not dismissing this issue, but we’ll need to investigate and determine out how we want to resolve it.
If you’re able to get a snapshot before and after the nfo changed it would be helpful in our investigation.
471 updated this morning again. Hundreds of updated files may not sound like a lot, but if you’re familiar with how snapraid works behind the scenes then you realize that this can have a major impact on the recoverability of the array. Adding new files is fine - they just won’t be protected until the next sync. But the data in existing files has been used to calculate the parity information, and that parity is only valid so long as all the other data still exists unchanged. Modifying a file is effectively the same as losing the file and would count as one failure in the recovery calculations (I run dual-parity - but what if 2 NFO’s on different data drives that are in the same stripe are both updated. What if its 3 files on 3 data drives…) At this point I’ve pretty much come to the conclusion that Sonarr’s metadata features are incompatible with snapraid as currently implemented.
I can think of all kinds of reasons I might want to change some of them. Maybe some people would want to increase the frequency of some tasks, or decrease others. In my case, if I could constrain the ‘Refresh Series’ task to only run once daily and ensure that that run is scheduled for about 20 minutes before my nightly snapraid-sync job, that would mostly mitigate the risks of having all these files being modified all the time. If the schedule can’t be forced to work together with my externally-scheduled snapraid jobs, then altering behavior to not modify the files is the only other option.
Are you developing an Apple product or something? All your users are too dumb to be given options? It seems like such a basic and obvious option to me to have a checkbox setting for all the metadata stuff to make it create-only - Sonarr’s purpose is to get content (and get associated metadata) and then to hand-off to other applications (plex, kodi, whatever) that actually use the content - let those applications manage any updates to metadata after that point if they are needed, and at the same time stop overwriting/reverting the changes that those applications make to the metadata.
I renamed and let snapraid recover one of the updated NFO’s this morning, and ran a diff between the two versions. The rating changed from 7.2 to 7.3. I don’t even care about ratings, I don’t look at them and would just as soon not even have that field in the metadata. So frustrating that such a stupid little thing can cause such problems.
If your other application(s) can update that metadata as needed, do you even need to create it within Sonarr in the first place? I don’t.
Switching off your metadata creation in Sonarr may be easier than trying to persuade Markus and the other devs to add a feature to solve a problem which only seems to affect snapraid users…
Some are, but like I said, people don’t read what options actually do before they start flipping switches. Drone Factory is named that way because there were countless people that set it to the same folder as their sorted files and caused a number of issues.
That’s what we thought it might be, but knowing thats the case helps.
Its an interval, not a set start time though, if you aligned it to run 20 minutes before the sync time by running it manually to reset the last run time then it would run again 24 hours from when it finished, every time it ran it would be pushed back the time it took to run., it may seem like a small thing, but the interval (regardless of time) is intentional otherwise you would get thousands of clients trying to update at the same time, the interval means its spread over the course of the day and the load doesn’t spike up.
Like I said, we’re not saying nothing will be done regarding the nfo updates, but we’re not going to make a snap decision.
