Sonarr version - 2.0.0.4689 OS Version - Win10 w/current updates: Debug logs
I turned on dubugging and will include as requested, but this would not have been running at the time of the initial problem.
(Make sure debug 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)
I will do as requested based on the previous note and instructions on whether to scan again or not now that debugging is on, etc. I also wanted to confirm this is not a more widespread issue already being worked instead of specific to me.
Description of issue:
I’ve been very deliberate in my download methodology by focusing on a custom Web-DL 720p only Profile with a DD5 Indexer requirement in the title. Once all of this is found, I remove the DD5 requirement and use the HDTV 720p profile with HDTV as a cutoff. This insures all of my initial downloads are 6 channel if Web-DL and are not overwritten. I have a personal dislike for 2 channel in my home theater and way too many of the Web-DL content fit that description if not DD5 specific. Further, I set the monitoring flag off for the episodes which are at the WEB-DL status. Recently I renamed a few of my directories to add the (year) to the Series name, and I had Sonarr scan again. After the scan, most of my episodes with the Web-DL status now have HDTV status. Fortunately, because of the way I set the flags, I am able to see which episodes have now changed status. I further confirmed this was a problem by installing Sonarr on a second PC which I use as a backup for the media. After scanning the whole backup drive, it reads everything as HDTV that was once Web-DL, even though I know the bulk of what I have is Web-DL. This means if I scan any more Series on my Primary, I will further corrupt what is being reported.
This is bad situation since I chose to download Web-DL at a higher cost in disk space over HDTV. In addition, had I not deliberately set the cut-off, everything would have tried to download again and wiped out a lot of block space. I’ve rescanned at other times in the past and did not notice this issue, so it “appears” new since recent updates, but I cannot swear to when exactly it started. Any ideas on why this is incorrectly reporting the Status? Now that debugging is on, should I scan again, or scan a different series, or should I avoid doing so in order to avoid adding to the problem with incorrectly reporting correct Status. Any and all help will be greatly appreciated.
If the filename doesn’t contain WEB-DL (or any other quality identifier) Sonarr will use the extension to find the quality, .mkv is HDTV-720p.
Scan again how?
Did you remove the series and re-add it or just update the path?
What does the episode history look like for one of the affected episodes?
When I changed the path with the directory rename, it was still showing 0 files until I told it to Update series info and scan disk. All episodes were now showing, but Web-DL Status was no longer present.
The episode history did not change as no new files were downloaded. The Status was simply updated after it found the series again.
That said, I’m confused by the reference to Sonarr interpreting all .mkv being HDTV-720p. If you allow Sonarr to rename the files after download like I do, then this would totally negate the distinct profile references used to monitor and select cut-offs between HDTV and Web-DL. If your cut-off was Web-DL, it would continually seek to download Web-DL whenever the Status was updated from Web-DL to HDTV - however this was initiated. Sonarr should not have to rely solely on the filename or default the Status based on the .mkv status since it maintains the original Quality status in the DB, particularly if it knows it did the rename. I don’t know the DB structure and application enough to know if there is a flag for Sonarr renaming an episode, but until now I assumed this would have to be the case. In looking at the DB, Quality is stored as its own table and per episode, so why would it ever need to update (downgrade) the Status again unless a new download was initiated, and even then, would it not log the status change as a new row in the table in order to go back if needed? I realize this latter might be more in the way of a feature change if it does no already perform this way, but how else would you maintain the Web-DL Status and avoid the issue I’m currently experiencing? As it stands, I’m stuck making sure I do not change any more paths or Update series info and scan disk if this is indeed what happened.
Thanks…
I might can write a SQL script to update my unmonitored episodes back to a Wed-DL status in the Quality table, but I would only do so as a last resort since it may prove to be temporary depending on the outcome of this discussion. If the behavior is definitely to change Quality status on an “Update series info and scan disk” based on the renamed file, and without regard to it potentially downgrading the status, then could this be viewed as a feature change? A check to see if Sonarr did the rename, and leave last know Quality status for values greater than the default name (ie; .mkv downgrading to HDTV)? Is there a different way to preserve the Web-DL status and avoid new downloads other than remove the ability for Sonarr to rename files? I’m assuming this may be an issue in Radarr as well and can test.
Only if the quality is not part of the filename and Sonarr needs to parse the file (new import or lost track of the file). If Sonarr never loses track of the file it knows the quality and can rename it later to include the quality.
Sonarr also adds deletion events to the history, if it can’t find a file after a rescan it will create an event in history and also create one if you deleted it from the UI.
If you add the quality to the filename and Sonarr loses track this won’t happen, if Sonarr never loses track of the files, this won’t happen either. I’m trying to understand exactly what happened to cause this, did you change the path in Sonarr or move the files first?
We need to know exactly what happened, so we can fix it, there are lots of ways to fix your issue right now (restore a backup, update the qualities via the UI or update them in the DB).
Don’t worry about trying to find a solution, Sonarr already tracks the quality of the episode file, the problem only arises if it loses track of the episode file and has to start from scratch.
I went back and reviewed the history in order to ascertain exactly what transpired. I had two affected series which listed all the episodes as deleted. I double checked my powershell window, and these two series were ones I had moved to a new drive, but only one had been renamed. It would appear the more the catalyst than the rename. In both instances I had to update the path, then I had to update the series and scan disk. I still have the issue where letting Sonarr rename (which is a cool feature as is the change of the date to the original air date), can create a change in status that will kick off the download again when the cuttoff is higher. I wanted to qualify the exact steps I had taken to help this make sense.
I see a couple potential issues that could cause this:
If the folder is in the old location still then the series is updated and the series rescanned, Sonarr would scan see the files missing and treat them as deleted.
If the folder was moved and Sonarr rescanned on the old folder it would also see them deleted and remove them from the database.
Im not sure I follow, if Sonarr is importing a new download, it’ll use the source file/folder name to determine the quality and store that internally/set that in the file name. If the cutoff is higher than the quality imported an upgrade could be grabbed later, but that’s expected give it hasn’t met the cutoff yet.