Not a preferred word

Sonarr version (exact version): 3.0.8.1507
Mono version (if Sonarr is not running on Windows): 6.12.0.122
OS: Linux/Docker
Debug logs:
Description of issue:
Keep getting a * Not a preferred word upgrade for existing episode file(s)

<!--- Additional Information: I keep getting this over and over with various downloads. I do have usenet set to a 60 minute delay for replication and torrents at 180 minutes since I prefer usenet... It seems like a release is downloading before another one then the queue processes and downloads a less preferred release. (ie: doesn't delete the other release from a queue and then it processes) Here's an example: existing file: ----.s03e05.seven_minutes_of_terror.atvp.webdl-2160p.HDR.10bit.hevc.eac3_atmos.5.1-ntb.mkv (NTB is a preferred release) ---.s03e05.hdr.2160p.web.h265-glhf.mkv ^ gets a status of * Not a preferred word upgrade for existing episode file(s) I can post a debug log if needed but wasn't sure if anyone had this also?

Queued items are not removed from queue nor do the docs we’ve mention that.

Sounds like you need to read the wiki to understand how delay profiles work

So items 2 and 3 on your wiki sound like what it should be doing in my case. Delay of 60 for Usenet, delay of 180 for torrent yet it downloads the torrent anyway after the fact.

If the wiki is suggesting I should use a delay of zero for Usenet, fine… I’ll try changing it but seems like it’s not doing what 2&3 say where it’ll ignore new items if a download is already matched with a preferred keyword.

If the grab happens before the preferred word release is found, Sonarr will grab the release and then if the preferred word release finishes first then it will be imported and the other will be left there for manual intervention.

Delay of 60 for Usenet, delay of 180 for torrent yet it downloads the torrent anyway after the fact.

Logs of this would be helpful to see what is going on, as would a screenshot of episode history.


Here’s the oldest I could find with the name from today:
https://zerobin.net/?1e4b10d7a102c0d1#WYB3soSPF+vsuyflqJ3JKKVUU1lJ97CgAKnQlk2Poho=

This happens often too… deletes the same release as the one it’s downloading.

Sharing an entire log file / thousands of lines with no context is a pretty big waste of time. What specific episode should we be looking for in the log? Those logs didn’t appear to have anything relating to a grab like Markus requested?

What are the contents of your release profiles?

What do the (I) show for the grab of the release that is stuck in your queue? What’s the time stamps of the back to back grabs?

As I stated above, that’s the last log I had for the For.All.Mankind.s03e05

I’ve changed the delay setting and am testing to see if it happens again.
If and when I notice it, I’ll try to get better logs.

To answer your other questions:

And to the last point, I’ve removed it since the logs have all rolled off.
As stated ^, I’ll try to watch it and see if it happens again since making the change to delays.

What do the (I) show for the grab of the release that is stuck in your queue? What’s the time stamps of the back to back grabs?

and this?

The mystery would be the grabs on Jun 16 and Jun 17. The grabs since then appear normal and are as expected based on your preferred words which are ALWAYS upgrades.

Not sure if there’s an easier way to get all the info but here’s some screen grabs:
(pictures below)

(1) First Grab:

(2) Deletes old:

(3) Imports:

(4) Grabs the same release again:

(5) Deletes the original file due to “upgrade”

(6) Imported:

(7) Downloads it again:

(8) Download Fails:

(9) Grabs again:

(10) Download fails:

(11) Grabs again:

(12) Deletes old:

(13) Imports:

(14) Grabs again:

(15) Download Fails:

(16) Grabs again this time via torrent:

(17) Deletes “old” again:

(18) Imports torrent:

From that point, it grabs the BTN and starts doing preferred word upgrades.

1 Like

LOL… ignore the numbers top right :slight_smile:

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