Skip to content

Navigation Menu

Sign in
Sign up

Feature Idea: Ability to choose what pipeline tag & quality profile filter applies to #11

mogno-jelly started this conversation in Ideas
Discussion options

I know this could be a specific use case, but I think it would be useful to have the option to choose what pipeline (any combination of backlog, cutoff unmet and/or custom format) a tag or quality profile filter applied to. Default can be for all.

For example, you're monitoring an ongoing series and some episodes picked up by backlog are under your custom format scoring. If I don't want to update my custom format scoring, there's currently no way to prevent those episodes from being reprocessed indefinitely (say I know that there won't be any better scored files to pickup) without also preventing the series from picking up future episodes as well. For this scenario, it'd be nice if I tagged the series and then in Nudgarr, filtered out only custom format for that tag. Future sweeps would still pick up backlog or cutoff unmet episodes for that series (i.e future or missing episodes) but not custom format items.

@MMagTech thoughts? (sorry to tag you but I know you mentioned that you didn't get notified before for discussions)

You must be logged in to vote

Replies: 4 comments 11 replies

Comment options

Wow not sure why I'm not getting notified of these tags/comments. Apologies for my confusion but, I'm not fully grasping this. Are you suggesting that excluded tags/filters be per pipeline and not globally as they are now? It's something I could look into. A quick look though as the code and pipeline are written now would require a major rewrite. I'd have to see if the juice is worth the squeeze.

You must be logged in to vote
1 reply
Comment options

No worries if it's not worth the trouble but yes, the idea is to be able to specify which pipeline(s) an exclusion tag/filter applies to.

Comment options

@mogno-jelly Just curious if you happen to be still using Nudgarr? I've been revisiting this idea and looking at implementing a feature branch separate from :latest to implement it. This is not a feature I'd use or that suites my library or 'arr setup. If implemented I'd need community feedback and testing. I'll do my best to ensure it's implemented correctly, do smoke test against a test simulated 'arr and can be side graded back to latest but, I wouldn't be able to make any guarantees to functionality on a live instance. If implemented this would definitely be a success of your feedback that other users could benefit form.

You must be logged in to vote
3 replies
Comment options

Yes, I'm definitely still using Nudgarr 😎
If you do implement it on a separate branch, I'd be happy to test it.
Thanks for revisiting this

Comment options

Awesome. I’ll go ahead and continue implementation on a :feature branch. I’ll tag you in a further comment when it’s live. Might be upwards to a week. Busy with work and other life events so progress is slow.

Comment options

I'll keep an eye out but no rush at all as this is more of nice to have

Comment options

@mogno-jelly

Before I look at building this, one question so I know it'd actually fix your case.

Are those episodes also showing up in Sonarr under Wanted → Cutoff Unmet?

Here's why I ask. In Nudgarr, the Cutoff Unmet and CF Score pipelines share the same "last searched" record for an episode. So if an episode is below your quality cutoff and below your custom format score, filtering it out of CF Score on its own wouldn't stop the searching — Cutoff Unmet would still pick it up and nothing would look any different to you.

If those episodes are not in Wanted → Cutoff Unmet — meaning the file quality itself is fine and it's only the custom format score that's low — then a CF-only filter would do exactly what you're describing.

Easiest way to check: Sonarr → Wanted → Cutoff Unmet, and see whether the episodes in question are in that list.

The issue, plainly:

Nudgarr keeps one "last searched" date per episode. Cutoff Unmet and CF Score both read and write that same date. Backlog keeps its own separate one.

So picture the feature working as intended. You tag a show and tell Nudgarr "don't run CF Score on this." Now:

If the episodes only have a low custom format score — the picture quality is fine, they just don't match your preferred release groups or formats — then CF Score was the only thing picking them up. Filter it out and the searching genuinely stops. The feature does exactly what was asked.

If those episodes are also below your quality target — say you want 1080p and they're 720p — then Cutoff Unmet is picking them up too. Turning off CF Score changes nothing visible, because Cutoff Unmet keeps searching them, and since both share that one date, the entries in History look identical either way.

That second case is the trap. Someone enables the feature, sees the same searches continuing, and reasonably reports it as broken — when it's working exactly as designed.

Why you can't just separate the dates: if Cutoff Unmet and CF Score each had their own, the same episode could be searched twice in a single sweep by two different pipelines. That doubles the hits on your indexers. The shared date is deliberately protecting against that, so it isn't something to "fix."

The upshot: the feature reliably isolates Backlog, and reliably isolates CF Score only for items that aren't also quality-cutoff-unmet. That's a narrower promise than three independent toggles would imply.

You must be logged in to vote
6 replies
Comment options

It's on a test image now if you want to try it against your setup. Just change from :latest to :feature

What it does: exactly what you described. With the feature enabled, each tag/profile filter gets a small C / B / F selector (Cutoff Unmet / Backlog / CF Score). Red = that pipeline skips items with the tag, grey = that pipeline ignores the filter. For your case: tag the series in Sonarr, filter that tag in Nudgarr, and leave only F red — CF Score stops reprocessing those episodes while Backlog and Cutoff Unmet keep picking up future/missing episodes for the series.

To test it:

Optional but smart: back up nudgarr-config.json from your config folder first.
Switch your image to ghcr.io/mmagtech/nudgarr:features or mmagtech/nudgarr:features and update/restart. The sidebar should show v5.1.0.
Go to Filters, flip the Pipeline Scope toggle in the top-right, load tags, and click the C/B badges on your tag's pill so only F stays red.
Apply. You'll get a prompt to update the CF index — take Sync Now so the already-indexed episodes drop out immediately instead of waiting for the next scheduled sync.
Everything is off by default — until you flip the toggle, the build behaves identically to v5.0.5.

Switching back: just point your compose back at :latest (or :5.0.5) and restart. No database changes in either direction. One thing to know: the older version doesn't understand scope, so your tag filter goes back to applying to all three pipelines — meaning Backlog/Cutoff would stop for that series again until you remove the filter or return to the feature build.

If it works for you (or doesn't), let me know here — this decides whether it ships in a proper release. Your feedback will be valued and appreciated.

Comment options

@MMagTech

That was faster than I expected haha. I tested the feature image out and it worked as expected from what I saw. After flipping "Pipeline Scope" on, updating the tag to only apply to F and syncing, episodes below the CF score no longer showed in the "CF Score" tab in Library. I deleted an episode to simulate a future episode coming out to confirm it would still pick up backlog and it did.

One thing I did notice was that for a tag that I had already added as a filter prior to switching to the test image, I was not shown the prompt to sync after I applied the tag badge updates. However, it did show for a new tag I added.

Thanks again for entertaining this

Comment options

@mogno-jelly Ended up being easier to implement than expected and had some free time to knock it out. Thanks for reporting back. I’ll let it ride on feature for a little before pushing to main for :latest. If you run into any bugs would value any bug reports from you.

Also, possibly any visual tweaks. Implementing into the ui for it to fit the current ui structure was my biggest issue. Still not sure how I feel. Hopefully as it landed is idea and makes sense. Tried to keep it minimal as to not require much ui real estate.

Once it goes down main I’ll update any necessary documentation like the wiki and site.

Comment options

Sounds like a plan - I'll stay on feature for now and will report back any bugs I see.

Have a good weekend!

Comment options

Great, thanks for putting reporting back so quickly and for the backlog simulation.

The sync prompt behaviour you noticed is actually intentiona. The prompt only appears when your change actually alters what belongs in the CF index. For the tag you'd added before switching images, its episodes were already excluded from the index (on 5.0.5, filters applied to all pipelines). Narrowing it to F-only changed nothing on the CF side, so there was nothing to sync and no prompt. For the new tag, its episodes were still in the index and needed to come out, so the prompt fired. Old behavior prompted on every save whether it mattered or not; this version only asks when a rebuild would actually do something.

Comment options

@mogno-jelly How's it been working out for you. Think it's good for main?

You must be logged in to vote
1 reply
Comment options

Thanks for checking in. It's working well in my use, no issues that stood out to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Ideas
Labels
None yet

AltStyle によって変換されたページ (->オリジナル) /