Duplicate grabs again

Help & Support
#1

Has been doing this for the last few days, this last time it got absurd. It has grabbed the EXACT same release from 3 different indexers. I hunted the first 2 & both even show as excepted.

I dont see how this thing is confused on this one, all 3 are the exact same (not even different release groups)

duplicates-again
duplicates-again1151×114 7.57 KB

duplicates
duplicates607×756 109 KB

All 3 where automatic grabs (green download arrow signifies grab vs manual)

20-5-10 20:10:21.5|Info|DownloadDecisionMaker|Processing 253 releases
20-5-10 20:10:21.5|Debug|DownloadDecisionMaker|Processing release 'The.Simpsons.S31E21.1080p.WEB.X264-ALiGN' from 'DigitalCore'
20-5-10 20:10:21.5|Debug|Parser|Parsing string 'The.Simpsons.S31E21.1080p.WEB.X264-ALiGN'
20-5-10 20:10:21.5|Debug|Parser|Episode Parsed. The Simpsons - S31E21 
20-5-10 20:10:21.5|Debug|Parser|Language parsed: English
20-5-10 20:10:21.5|Debug|QualityParser|Trying to parse quality for The.Simpsons.S31E21.1080p.WEB.X264-ALiGN
20-5-10 20:10:21.5|Debug|Parser|Quality parsed: WEBDL-1080p v1
20-5-10 20:10:21.5|Debug|Parser|Release Group parsed: ALiGN
20-5-10 20:10:21.5|Debug|AcceptableSizeSpecification|Beginning size check for: The.Simpsons.S31E21.1080p.WEB.X264-ALiGN
20-5-10 20:10:21.5|Debug|AcceptableSizeSpecification|Max size is unlimited, skipping size check
20-5-10 20:10:21.5|Debug|AcceptableSizeSpecification|Item: The.Simpsons.S31E21.1080p.WEB.X264-ALiGN, meets size constraints
20-5-10 20:10:21.5|Debug|AlreadyImportedSpecification|Performing already imported check on report
20-5-10 20:10:21.5|Debug|AlreadyImportedSpecification|Skipping already imported check for episode without file
20-5-10 20:10:21.5|Debug|LanguageSpecification|Checking if report meets language requirements. English
20-5-10 20:10:21.5|Debug|MaximumSizeSpecification|Maximum size is not set.
20-5-10 20:10:21.5|Debug|MinimumAgeSpecification|Not checking minimum age requirement for non-usenet report
20-5-10 20:10:21.5|Debug|QualityAllowedByProfileSpecification|Checking if report meets quality requirements. WEBDL-1080p v1
20-5-10 20:10:21.5|Debug|ReleaseRestrictionsSpecification|Checking if release meets restrictions: The.Simpsons.S31E21.1080p.WEB.X264-ALiGN
20-5-10 20:10:21.5|Debug|ReleaseRestrictionsSpecification|[The.Simpsons.S31E21.1080p.WEB.X264-ALiGN] No restrictions apply, allowing
20-5-10 20:10:21.5|Debug|RetentionSpecification|Not checking retention requirement for non-usenet report
20-5-10 20:10:21.5|Debug|DelaySpecification|QualityProfile does not require a waiting period before download for Torrent.
20-5-10 20:10:21.5|Debug|HistorySpecification|Performing history status check on report
20-5-10 20:10:21.5|Debug|HistorySpecification|Checking current status of episode [40388] in history
20-5-10 20:10:21.5|Debug|DownloadDecisionMaker|Release accepted
20-5-10 20:10:21.5|Debug|DownloadDecisionMaker|Processing release 'The.Simpsons.S31E21.720p.WEB.X264-ALiGN' from 'DigitalCore'
20-5-10 20:10:21.5|Debug|Parser|Parsing string 'The.Simpsons.S31E21.720p.WEB.X264-ALiGN'
20-5-10 20:10:21.5|Debug|Parser|Episode Parsed. The Simpsons - S31E21 
20-5-10 20:10:21.5|Debug|Parser|Language parsed: English
20-5-10 20:10:21.5|Debug|QualityParser|Trying to parse quality for The.Simpsons.S31E21.720p.WEB.X264-ALiGN
20-5-10 20:10:21.5|Debug|Parser|Quality parsed: WEBDL-720p v1
20-5-10 20:10:21.5|Debug|Parser|Release Group parsed: ALiGN
20-5-10 20:10:21.5|Debug|AcceptableSizeSpecification|Beginning size check for: The.Simpsons.S31E21.720p.WEB.X264-ALiGN
20-5-10 20:10:21.5|Debug|AcceptableSizeSpecification|Max size is unlimited, skipping size check
20-5-10 20:10:21.5|Debug|AcceptableSizeSpecification|Item: The.Simpsons.S31E21.720p.WEB.X264-ALiGN, meets size constraints
20-5-10 20:10:21.5|Debug|AlreadyImportedSpecification|Performing already imported check on report
20-5-10 20:10:21.5|Debug|AlreadyImportedSpecification|Skipping already imported check for episode without file
20-5-10 20:10:21.5|Debug|LanguageSpecification|Checking if report meets language requirements. English
20-5-10 20:10:21.5|Debug|MaximumSizeSpecification|Maximum size is not set.
20-5-10 20:10:21.5|Debug|MinimumAgeSpecification|Not checking minimum age requirement for non-usenet report
20-5-10 20:10:21.5|Debug|QualityAllowedByProfileSpecification|Checking if report meets quality requirements. WEBDL-720p v1
20-5-10 20:10:21.5|Debug|ReleaseRestrictionsSpecification|Checking if release meets restrictions: The.Simpsons.S31E21.720p.WEB.X264-ALiGN
20-5-10 20:10:21.5|Debug|ReleaseRestrictionsSpecification|[The.Simpsons.S31E21.720p.WEB.X264-ALiGN] No restrictions apply, allowing
20-5-10 20:10:21.5|Debug|RetentionSpecification|Not checking retention requirement for non-usenet report
20-5-10 20:10:21.5|Debug|DelaySpecification|QualityProfile does not require a waiting period before download for Torrent.
20-5-10 20:10:21.5|Debug|HistorySpecification|Performing history status check on report
20-5-10 20:10:21.5|Debug|HistorySpecification|Checking current status of episode [40388] in history
20-5-10 20:10:21.5|Debug|DownloadDecisionMaker|Release accepted

20-5-10 20:10:23.7|Debug|QBittorrent|Downloading torrent for episode 'The.Simpsons.S31E21.1080p.WEB.X264-ALiGN' finished (29738 bytes from http://127.0.0.1:9117/dl/digitalcore/?jackett_apikey=(removed)&path=Q2ZESjhEa3pjTGtMcWpKRXNlZmtVQlpWRUtHZFVFWHNIWTFDc0NOOURNcDdOTDZETHc2R24yR25zU0QyOUx3dW9Ia2h3Zm8zdW1FZGphMGlobWxWTGZuNThnOUtmQmpMSGFzQUpyQ2tDRDY1UzFEdDhtdkZWTG1pNU9QLWF0VGhYcy15S0VIWnVKWEdoUy1uM3JKZVRSX3ZpY19WYmFuYmszbzVwVF9ETFgxV3lMOExUd2VrNEpUSEJnRkpHVGxuWWdwRkt3&file=The.Simpsons.S31E21.1080p.WEB.X264-ALiGN)
20-5-10 20:10:23.7|Info|DownloadService|Report sent to qBittorrent. The.Simpsons.S31E21.1080p.WEB.X264-ALiGN


20-5-10 20:43:23.9|Debug|DownloadDecisionMaker|Processing release 'The Simpsons S31E21 1080p WEB X264-ALiGN' from 'Speed'
20-5-10 20:43:23.9|Debug|Parser|Parsing string 'The Simpsons S31E21 1080p WEB X264-ALiGN'
20-5-10 20:43:23.9|Debug|Parser|Episode Parsed. The Simpsons - S31E21 
20-5-10 20:43:23.9|Debug|Parser|Language parsed: English
20-5-10 20:43:23.9|Debug|QualityParser|Trying to parse quality for The Simpsons S31E21 1080p WEB X264-ALiGN
20-5-10 20:43:23.9|Debug|Parser|Quality parsed: WEBDL-1080p v1
20-5-10 20:43:23.9|Debug|Parser|Release Group parsed: ALiGN
20-5-10 20:43:24.0|Debug|AcceptableSizeSpecification|Beginning size check for: The Simpsons S31E21 1080p WEB X264-ALiGN
20-5-10 20:43:24.0|Debug|AcceptableSizeSpecification|Max size is unlimited, skipping size check
20-5-10 20:43:24.0|Debug|AcceptableSizeSpecification|Item: The Simpsons S31E21 1080p WEB X264-ALiGN, meets size constraints
20-5-10 20:43:24.0|Debug|AlreadyImportedSpecification|Performing already imported check on report
20-5-10 20:43:24.0|Debug|CutoffSpecification|Comparing file quality and language with report. Existing file is WEBDL-1080p v1 - English
20-5-10 20:43:24.0|Debug|UpgradableSpecification|Comparing preferred word score. Current: 0 New: 19
20-5-10 20:43:24.0|Debug|LanguageSpecification|Checking if report meets language requirements. English
20-5-10 20:43:24.0|Debug|MaximumSizeSpecification|Maximum size is not set.
20-5-10 20:43:24.0|Debug|MinimumAgeSpecification|Not checking minimum age requirement for non-usenet report
20-5-10 20:43:24.0|Debug|QualityAllowedByProfileSpecification|Checking if report meets quality requirements. WEBDL-1080p v1
20-5-10 20:43:24.0|Debug|ReleaseRestrictionsSpecification|Checking if release meets restrictions: The Simpsons S31E21 1080p WEB X264-ALiGN
20-5-10 20:43:24.0|Debug|ReleaseRestrictionsSpecification|[The Simpsons S31E21 1080p WEB X264-ALiGN] No restrictions apply, allowing
20-5-10 20:43:24.0|Debug|RetentionSpecification|Not checking retention requirement for non-usenet report
20-5-10 20:43:24.0|Debug|UpgradeAllowedSpecification|Comparing file quality and language with report. Existing file is WEBDL-1080p v1 - English
20-5-10 20:43:24.0|Debug|UpgradeDiskSpecification|Comparing file quality and language with report. Existing file is WEBDL-1080p v1 - English
20-5-10 20:43:24.0|Debug|UpgradableSpecification|Comparing preferred word score. Current: 0 New: 19
20-5-10 20:43:24.0|Debug|UpgradableSpecification|New item has a better preferred word score
20-5-10 20:43:24.0|Debug|DelaySpecification|QualityProfile does not require a waiting period before download for Torrent.
20-5-10 20:43:24.0|Debug|HistorySpecification|Performing history status check on report
20-5-10 20:43:24.0|Debug|HistorySpecification|Checking current status of episode [40388] in history
20-5-10 20:43:24.0|Debug|DownloadDecisionMaker|Release accepted

I see New item has a better preferred word score however:

  • My release profiles have not changed
  • The first one it downloaded was actually a score of 20 which would have been higher so not sure why it says 0 (Digitalcore = 20, Speed = 19, IPT = 18, Torrentday = 17)
  • It is the exact same release, name/size/group/etc so why would it even try to download it again anyways!!??!! Maybe if there where a higher quality but it is identical.

Edit - Now as of this morning it grabbed rick and morty 3 times & the rookie FIVE damn times

#2

Trace logs will show what Sonarr is using to calculate the zero score, my guess it’s using the filename because it doesn’t have a scene name. If that’s the case then the why is the next problem, which could be because Sonarr lost track of the file (it was renamed after sorting) or didn’t use the file/folder name for some reason.

The logic for determining the scene name is here:

#3

Can it not check the db and compare the release to an existing one and see if is the exact same? Sonarr stores the full release info so this should be a possibility to avoid having the exact same one over & over right? Would at least fix that part of the problem

#4

It compares to what it has for the existing file.

It stores some of the release info, but it doesn’t care about that, only the file.

You need to figure out exactly what the issue is, right now you’re trying to find a solution without knowing exactly where it’s failing.

#5

Ive enabled trace logging so i’ll post that back when it happens again.

#6

Ok, so i disabled the usage of release profiles but that didn’t fix the problem. Last night 4 grabs of the same exact release. Once from each indexer. I went through all the logfiles and did a search for “The.Blacklist.S07E19.720p.WEB.H264-MEMENTO” in the debug logs, 5 of them, (i can attach if you like but seem pointless) and there are not even entries for 3 of the 4 grabs. So the question becomes how did sonarr grab them without logging them?

#7

It wouldn’t have, if they’re not logged and in Sonarr’s history then Sonarr didn’t grab them.

#8

So the issue is they are mis-labeled in the logs then because they ALL show the same indexer (timestamps in the log match the ones in qBittorent) and they say they where ignored. Yet the grabs are clearly in qbitorrent and they all show in the episode history for that specific episode (except in the history the indexers are accurate).

  • 3:28 am grab from DC, this is accurate
  • 3:44 am grab from SCD, log shows it was DC and it was ignored (not accurate as it was grabbed, downloaded & imported as an upgrade which the history of the episode also shows this)
  • 4:18 am grab from IPT, log shows it was DC and it was ignored (not accurate as it was grabbed, downloaded & imported as an upgrade which the history of the episode also shows this)
  • 4:34 am grab from TD, log shows it was DC and it was ignored (not accurate as it was grabbed, downloaded & imported as an upgrade which the history of the episode also shows this)
#9

And again…

8:17 grab (DigialCore)
8:33 grab (Speed)
9:07 grab (TorrendDay)

so i am sure it will be grabbed 2 more times for the other indexers…

https://filebin.net/wanpv26odd87j0o0 log files for these 3 grabs. It is clearly sending these to qBit over and over and over. It is also trying to send for the ones it has already sent every time it runs too but they are rejected by qBit since it has already done it (thankfully that checks duplicates or this would be insane lol).

The.Simpsons.S31E22.1080p.WEB.H264-ALiGN is what you would be looking at.

#10

while they may be the exact same file they cant be the exact same torrent in all those indexers, the hash for each one must be different or sonarr wouldnt download it again.

the logs you posted appear to be for the first download as its says there is no existing episode to check the history for (unless im reading that wrong)
20-5-10 20:10:21.5|Debug|AlreadyImportedSpecification|Skipping already imported check for episode without file

does a file ever end up in sonarr? does it end up in the correct series/season path?

could you confirm what version of sonarr you have

could you also provide debug logs of the actual download completion and import stage. if theres an issue with the import then it would make sense for sonarr to continually grab the show from the rss feed. ie if its an lnk file (spam/virus) and not a proper video file.

#12

Well they are different indexers so naturally the hash is different for that reason. I understand it wouldn’t download the same hash each time. When i say the exact same, it is the same release & release name just a different site.

I have already added log files for the multiple download again tonight.

Version is current for v3 (as of tonights release)

Based on the notifications it is successful each time as i get upgrade notifications. They also show in the episode history as mentioned before as an upgrade each time which also leads me to believe there is no error during the process.

Here is also a screenshot of the history + recycle bin

#13

grab-817.txt, I don’t see any releases grabbed, though I see lots of failed grabs (15 times QBit failed to add the download to the queue).

grab-833.txt, 2 grabs, 31 failures. The second grab has a better preferred word score (18 vs 0), but without trace logs we don’t know where the 0 came from.

grab-907.txt, 1 grab, 17 failures.

20-5-17 21:07:05.0|Debug|UpgradableSpecification|Comparing preferred word score. Current: 0 New: 19
20-5-17 21:07:05.0|Debug|UpgradableSpecification|New item has a better preferred word score

Again, without trace logs, we’re blind to where it came from.

I noticed that all The Simpsons releases in the logs spaces are used instead of periods, if the resulting filename also contains spaces instead of periods it’s likely Sonarr isn’t restoring a release name as the scene name and it’s forced to match via the file name.

QBit failing to add downloads could be a problem that’s silently grabbing releases that don’t end up in Sonarr’s history, because Qbit says it failed to add the download, but it actually succeeded, though that’s the only issue here.

#14

The 8:17 grab is in the 2nd file.

20-5-17 20:17:14.5|Debug|QBittorrent|Downloading torrent for episode 'The.Simpsons.S31E22.1080p.WEB.H264-ALiGN' finished (29338 bytes from http://127.0.0.1:9117/dl/digitalcore/?jackett_apikey=(removed)&path=Q2ZESjhLYTJMcDFncHFsQXJjUEh5MXplbVo1Qnk0U3JGdHhUdXBtdVU2cEZkWmtYa25qQWNyZVNmTDE1Q0R0dGdsdUFwR2dRdElFdnRodk90WWdmakxUSlJpMm5VWVJ4RUI2Rlp3UWRaWF9ONU1FU3JMdUhMQ0lwNjFNdFk0SmJIdXROOWozRDRJSFNWdjJHMDA2WnN6cW56Vk83OUNXdHFGZTZiUXB5SXlCMGQ3VllDQXZhSmRjdU1FVEVkeTVfSlRlTGZn&file=The.Simpsons.S31E22.1080p.WEB.H264-ALiGN)
20-5-17 20:17:14.8|Info|DownloadService|Report sent to qBittorrent. The.Simpsons.S31E22.1080p.WEB.H264-ALiGN
20-5-17 20:29:23.8|Debug|EpisodeFileMovingService|Copying episode file: T:\Deluge\Complete\TV Shows\The.Simpsons.S31E22.1080p.WEB.H264-ALiGN\The.Simpsons.S31E22.1080p.WEB.H264-ALiGN.mkv to D:\Plex\TV Shows\The Simpsons\Season 31\The Simpsons - S31E22 - The Way of the Dog WEBDL-1080p.mkv
20-5-17 20:29:23.8|Debug|DiskTransferService|Copy [T:\Deluge\Complete\TV Shows\The.Simpsons.S31E22.1080p.WEB.H264-ALiGN\The.Simpsons.S31E22.1080p.WEB.H264-ALiGN.mkv] > [D:\Plex\TV Shows\The Simpsons\Season 31\The Simpsons - S31E22 - The Way of the Dog WEBDL-1080p.mkv]

Subsequent failures from qBit are because Sonarr keeps trying to send the same file which qBit already has. It is the same release from the same indexer (Digitalcore) so therefor it has the same hash and doesn’t add. That seems like another issue in its self but relates to sending it over and over. Why keep sending what has already been successfully sent and processed… Digitalcore was successfully processed at 8:17 & imported at 8:29 so why would it keep trying to send it to qBit

Failure, digitalcore again

20-5-17 20:33:48.4|Debug|QBittorrent|Downloading torrent for episode 'The.Simpsons.S31E22.1080p.WEB.H264-ALiGN' finished (29338 bytes from http://127.0.0.1:9117/dl/digitalcore/?jackett_apikey=(removed)&path=Q2ZESjhLYTJMcDFncHFsQXJjUEh5MXplbVo2NER4SFl2U3o2UzJWTDFFWlB6WDBqMTNUbzJkdEk5MU1LcTJkUWN2UzE4aHM4SDE2Z1E3RzFGNlczR19FaGtOM0pwaWlSb0FyeFg4QWYybXh2UG9iUmMzQWxnMHUyU0NPUElMYXNhSWdhd1dhbE9SNTlzcHRGNTByOUFCRUVOWkwzUUdrYXM2cmpqOTNrWVhqTXpaank2Zm5Ma0Q5TEdjaWJaRjdyMTduLWRn&file=The.Simpsons.S31E22.1080p.WEB.H264-ALiGN)
20-5-17 20:33:48.4|Warn|ProcessDownloadDecisions|Couldn't add report to download queue. The.Simpsons.S31E22.1080p.WEB.H264-ALiGN

Failure, digitalcore again

20-5-17 21:07:07.7|Debug|QBittorrent|Downloading torrent for episode 'The.Simpsons.S31E22.1080p.WEB.H264-ALiGN' finished (29338 bytes from http://127.0.0.1:9117/dl/digitalcore/?jackett_apikey=(removed)&path=Q2ZESjhLYTJMcDFncHFsQXJjUEh5MXplbVo2Q2lESmUzNEVhbGtEcFJWVTBJeC1BN1FoSFRDdVZoR0JrU0xZTTR1UzV3MW03cDB5S2hNRE1PYmUzNVhIOFIyX0NKR0dPOUJkMVdZR2JZTFRWc204TFVFcndZRzRpZm8yeTg2TWVURVJGN3QtaXVTOUd0OUlxZTY3dDRrdDUwNENuV1FySDZEenJfYXVTVGJLTUd1bHgxb3dfVnFOTG5zNFVidDRxNkF3RFBR&file=The.Simpsons.S31E22.1080p.WEB.H264-ALiGN)
20-5-17 21:07:07.7|Warn|ProcessDownloadDecisions|Couldn't add report to download queue. The.Simpsons.S31E22.1080p.WEB.H264-ALiGN

Looking at the other failures, they are the same problem. See, i was the uploader for the failing she-ra’s so the hash is already in use in qBit but sonarr is trying to grab them anyways but qBit refuses because it already has them.

qBit is doing exactly what it should be doing from what i see, not allowing the download of duplicates that sonarr keeps trying to throw at it.

#15

Makes sense, still some preferred words causing upgrades then, since it’s not 0, but we don’t know what it’s comparing to.

#16

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.