Sonarr / Sonarr

Smart PVR for newsgroup and bittorrent users.
https://sonarr.tv
GNU General Public License v3.0
10.6k stars 1.34k forks source link

Tags are seemingly ignored now? Just started happening over the last couple months. #6609

Closed ShaneIsrael closed 6 months ago

ShaneIsrael commented 6 months ago

Is there an existing issue for this?

Current Behavior

I have tags for all of my anime series so that Sonarr only downloads from specific release groups. These have always worked perfectly up until a couple months ago. I am not sure what changed, but suddenly it seems like sonarr is ignoring my tags and downloading episodes from one specific release group.

image

image

Multiple shows I have are now downloading initially from this -kawaii[EZTVx.to]. However, if I remove the episode and manually search Sonarr finds the correct episode that matches my tag.

Here is how I have my tag. This also happens with my other tags for various other release groups as well, and I have them in the exact same format. Again, this only started happening about 2 months ago and I've had sonarr setup this way without issue for a couple years now. image

Expected Behavior

Only download episodes with titles that contain the "must contain" episodes listed in the tags.

Steps To Reproduce

No response

Environment

- OS: Unraid
- Sonarr: 4.0.2.1183
- Docker Install: Yes

What branch are you running?

Main

Trace Logs?

none

Anything else?

No response

markus101 commented 6 months ago

Please use one of the support channels: forums, subreddit, discord , or IRC for support/questions.

ShaneIsrael commented 6 months ago

@markus101 this isn't a support question, it's a bug. What makes you think this is a support question?

Thirrian commented 6 months ago

My $0.02: It's a very slim chance of a simple functionality like this suddenly breaking. All support channels would be flooded with users reporting this. There's not even a single "me too" here...

For what it's worth, I have multiple "must contain" rules working fine. Also, seems a bit redundant to include the same term with and without braces. It's just a simple "does the text (release) contain this or not" comparison iirc...

Finally: no evidence of the perceived bug (debug or trace logs) is provided.

If this was at work, where I have dev colleagues who get paid for stuff like this, they'd shrug and close my ticket.

ShaneIsrael commented 6 months ago

@Thirrian I have both because releases will often be either [EMBER] some relase name title etc or EMBER some release name title and like I said, I've had these set without issue for a couple years now and only over the last 2 months have they started picking up the wrong release. What's weird is that its always picking up this "kawaii" release from "EZTV.to".

Not just my EMBER tag, but I have other tags in the same format. These tags are also specified to only grab releases from my Nyaa.si indexer. However, these releases they are now grabbing are coming from my EZTV indexer. So that to me is very clearly sign of a bug.

Even if the "must contain" I have is incorrect, the tag clearly states the indexer to use but its instead grabbing stuff from my other indexers. image

Here is another example I just found. As you can see it doesn't always happen. This week, it grabbed the correct episode with the [SubsPlease] tag. But last week, it grabbed the kawaii.to release. image image

Notice the title? It doesn't contain my tag requirements at all. image

And when you do an interactive search, that kawaii.to release doesn't show up at all. In fact the release it should have grabbed shows up correctly right at the top as you'd expect. image

So I have no idea why it is grabbing this kawaii.to release from my EZTV indexer when the tag clearly states to only use Nyaa.si and also clearly states that it must container SubsPlease or [SubsPlease].

Something somewhere is bugged. My theory is that the first time it does the search for the episode when a new episode releases, if it doesn't see one that matches the tag, its automatically searching other indexers and grabbing the first thing that comes up that matches the shows name, which seems to always be the EZTV release by kawaii.to

ShaneIsrael commented 6 months ago

Just to add to my last reply, I deleted that kawaii.to episode. Told it to re-search (using automatic) and it immediately found the correct episode like it should. So I'm pretty convinced that its only an issue when Sonarr kicks off the first automatic search on a new release. image

markus101 commented 6 months ago

Incomplete bug reports that are very likely not bugs aren't going to be kept open. To add onto Thirrian's response, especially when support channels and GitHub issues aren't filled with a "bug" that has existed for months for a heavily used feature. Sometimes our first look is wrong and issues can be reopened when proven to be bugs. Opening bugs for misconfigurations is a waste of everyone's time, I have no doubt if you'd hopped into Discord (for real-time support) this issue would already be resolved.

Your first example doesn't show that the series has the tag uploader-ember, but also the release profile is limited to only Nyaa.si, so anything from another indexer would not require that uploader. Your history doesn't show any information about the grabbed release other than it was grabbed. Did that release even come from Nyaa.si? I did a quick search on Nyaa and didn't see a release with that name and given it's tagged with EZTV it's much more likely it came from not Nyaa given they have two releases total with eztv in the name.

when Sonarr kicks off the first automatic search on a new release.

This is not how Sonarr finds episodes, how Sonarr finds episodes is explained in the FAQ.

If you have further questions, please use one of the support channels mentioned above.

ShaneIsrael commented 6 months ago

the release profile is limited to only Nyaa.si

This I believe was the root of the issue. For some reason I misread this as only using this indexer. So my thought was that any show using this tag, would only search from that indexer. image

I believe changing that back to any will solve the problem.

I apologize for stressing that it was a bug, that misunderstanding on my part made it seem very much like a bug. Maybe the wording around that can be improved?