Version 3.0.10.1567
Package Version 3.0.10.1567-ls206 by linuxserver.io
Mono Version 6.12.0.200
OS Ubuntu 20.04 LTS
I do not have logs so this is more of a general inquiry. I have seen in the forum history a similar issue about 3 years ago where Sonarr kept downloading and importing the same NZB over and over as I am experiencing now. It doesn’t do this all the time and seems to be more of an issue with certain shows as compared to others.
This issue happened again and I was able to get two events in the same log file. The NZB it is occurring with is “The Great British Bake Off An Extra Slice S10E05 1080p HDTV H264-DARKFLiX”.
they were found in the RSS feed from both nzbgeek and nzbplanet at 20:18 and 20:34. sonarr rejected them because that episode is no longer monitored so its working correctly.
part of your issue is that the feeds from your usenet indexers appear to be returning the exact same info every time when they should only be showing new stuff from the last feed update.
need to confirm this as theres no datetime stamp in the requests and i was under the impression that only the “new” returns were processed but it appears that may not actually be the case and it just asks for the last X number of records. so if your indexer doesnt have anything newer since the last feed you get the same results as the previous feed and it processes them again (which seems rather wasteful)
the other part is that sonarr will only download the same nzb if it thinks its an upgrade. so when this happens it somehow thinks it is an upgrade or it wouldnt do it and the only way to work out why it thinks its an upgrade is with the logs from when it actually happens.
ie sonarr has to accept the download - and the logs will show why it did. then you can work out why its happening.
btw, its impossible for this to happen with torrents as sonarr will not process the same hash again. nzbs dont have that info so it can grab it again if it thinks its an upgrade. if your show is predominantly nzb based then its more likely to happen.
note - mousing over those info icons should also give you some information on why, eg preferred word score should be higher, and the deletions should be due to an upgrade
It is actually happening at the moment with a different TV show. The logs I provided were unedited so would include the information you thought would be necessary (unless you need both the debug log and the standard log as I only provided debug).
I clicked on the delete icon in the history for the series that is currently doing this and it thinks that as you suggested, it is upgrading the episode.
The other thing I should mention is that because NZBs have no upload requirement my system has a 1 hour delay on pretty much all Torrents meaning that I prefer NZBs all things being equal. There are a couple of series that don’t get released on NZB so I use a tag to flag them for immediate download on Torrent and bypass the delay.
Here is my delay profiles…
The series that have been having this issue do not have a tag on them.
battlebots isnt in the currently attached logs so i cant tell.
youve got a preferred word score so it shouldnt be downloading anything unless its got a higher score.
the only reason i can think of for it happening is the download says its 1080p but the downloaded file scans at something lower so its always an upgrade due to the nzb filename mismatch.
ie if the nzb name says its 1080p but the file inside is actually 720p then sonarr will notice that and the next time it sees the 1080p nzb name it will download it again.
in your case it doesnt look like this is happening but from the series page what quality does sonarr think the downloaded file ended up as? 1080p WEBDL, or something else?
a similar thing can happen for WEBDL/WEBRIP depending if you sort those out individually, or group them up, and your filename just has WEB so im not sure what that converts to by default (WEBDL or WEBRIP)
ie your nzb filename has WEB but the sonarr filename has WEBDL
could you check your quality profiles to see how youre grouping and/or prioritising them?
I think you may be on to something as the predominant profile I assign to series is called “Best Effort”. Here is its profile…
Do you know how that code works when you group two quality labels like WEBRip and WEBDL into one group? My assumption was that in a case like that, either one should satisfy the quality requirement otherwise if they still had precedence within the group there is no advantage to using a group. I wonder if the code is bugged when “Rip” or “DL” is not declared on the NZB itself. Inside the “WEB 1080p” group DL has a higher priority in the stack than Rip and the downloaded file is WEBDL (I include it in the filename output in the Media Management Profile). Whatever is occurring is not consistent as last night it downloaded from the same group who only declare “WEB” on their NZBs but stopped once the quality profile was met (i.e. it originally downloaded a 720p version and then upgraded to 1080p and stopped)…
With Battlebots it didn’t go through the 720p upgrade stage though as the original NZB it started with was the one it keeps retrieving over and over.
when you put two qualities into the same group they are considered identical for upgrade purposes so internal order makes no real difference. i think, but not 100% sure, the only time the order inside the group might make a difference is when it gets both of them at the same time in the same feed and both are an upgrade to what you originally had, it might pick the higher one at that point.
in your case WEBDL and WEBRIP should never upgrade between the two (based solely on quality), something else has to change for it to upgrade. its why having the logs for one of those grabs would be really helpful, it would have the reason why it was seen as an upgrade in there.
what does a battlebots episode history look like for one that keeps updating?
Here is the history. You can see it only ever downloads the same NZB over and over without starting at 720p (I turned off monitoring to get it to stop). The first grab of the NZB it was on the NZBGeek indexer for 13 minutes and it was then grabbed the second time from the same indexer 15 minutes later. The third grab was from NZBPlanet who had it for 9 minutes at that time. It continued pulling sometimes from NZBGeek and sometimes from NZBPlanet until I intervened.
considering its the same quality then all thats really left is the preferred word score. its seeing the nzb with a score of 100, but perhaps its score is regenerated after download and gets a lower score.
i dont think theres any way to visually see the current preferred word score for a downloaded file though.
the only real way to work out part of why its constantly downloading is to monitor an episode that you know gets grabbed repeatedly until it grabs it again, then unmonitor it, and then upload the logs for that grab. you may want to pause sab so it doesnt actually download anything while youre doing this.
what were looking for are entries like these
2023-07-11 17:35:54.1|Debug|UpgradableSpecification|Comparing preferred word score. Current: 0 New: 0
2023-07-11 17:35:54.1|Debug|UpgradableSpecification|Existing item has an equal or better preferred word score, skipping
I actually just found the problem. The issue is that I have a preferred profile for 5.1 audio…
It looks like whenever it runs across an episode 5 1080p episode that it needs to download it is posted as (in the case of Battlebots) S10E05.1080p and you can see the 5.1 string in the middle of that text causing the +100 during parsing. The downloaded filename has a completely different naming scheme and does not trigger the 5.1 string parse so the preferred word is causing the upgrade.
2023-11-02 23:51:39.8|Debug|DownloadDecisionMaker|Processing release 'BattleBots.2015.S09E05.1080p.WEB.h264-EDITH' from 'NZBFinder.ws'
2023-11-02 23:51:39.8|Debug|Parser|Parsing string 'BattleBots.2015.S09E05.1080p.WEB.h264-EDITH'
2023-11-02 23:51:39.8|Debug|Parser|Episode Parsed. BattleBots 2015 - S09E05
2023-11-02 23:51:39.8|Debug|Parser|Language parsed: English
2023-11-02 23:51:39.8|Debug|QualityParser|Trying to parse quality for BattleBots.2015.S09E05.1080p.WEB.h264-EDITH
2023-11-02 23:51:39.8|Debug|Parser|Quality parsed: WEBDL-1080p v1
2023-11-02 23:51:39.8|Debug|Parser|Release Group parsed: EDITH
2023-11-02 23:51:39.8|Debug|AcceptableSizeSpecification|Beginning size check for: BattleBots.2015.S09E05.1080p.WEB.h264-EDITH
2023-11-02 23:51:39.8|Debug|AcceptableSizeSpecification|Item: BattleBots.2015.S09E05.1080p.WEB.h264-EDITH, meets size constraints
2023-11-02 23:51:39.8|Debug|AlreadyImportedSpecification|Performing already imported check on report
2023-11-02 23:51:39.8|Debug|CutoffSpecification|Comparing file quality and language with report. Existing file is WEBDL-1080p v1 - English
2023-11-02 23:51:39.8|Debug|UpgradableSpecification|Comparing preferred word score. Current: 0 New: 100
Now my next question is can you think of a way to prefer 5.1 audio without triggering this condition? I guess if I turn on “Include Prefered when Renaming” it should put 5.1 into the filename. Do I need to also make any changes in the “Standard Episode Format”?
Edit: I added the {Preferred Word} Meta Tag to the Episode Format.
yes, the 5.1 was matching too much as its too short, you probably want to use /5\.1[. -]/i so its at least looking for a separator of some sort after the 5.1
you could also add ddp in front to ensure its about dolby 5.1, eg /ddp? ?5\.1[. -]/i
either way it looks like you will need to ensure the resulting filename contains the preferred words as well so its scored properly.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.