Describe the bug
Maintainerr rules are processing media that has been previously removed from its collections (visually at least), from Jellyfin, and from Sonarr.
While this is happening, CPU usage on Jellyfin maxes out on however many cores you allow Jellyfin to use concurrent threads for.

To Reproduce
This is how I think the issue can be reproduced.

1. Add the rule below, name it Watched - Episodes or whatever value you set the 2nd condition in the rule to match on.
2. Add a different rule eg. Delete after 1 day that cleans up some media that is also in the Watched - Episodes collection
3. Run the Delete after 1 day rule
4. Run the Watched - Episodes rule after Delete after 1 day has removed the media that was present in both collections

Maintainerr displayed that it was processing this rule the last time I noticed the behaviour:

mediaType: EPISODES
rules:
  - "0":
      - firstValue: Jellyfin.isWatched
        action: EQUALS
        customValue:
          type: boolean
          value: "true"
      - operator: OR
        firstValue: Jellyfin.collection_names
        action: CONTAINS
        customValue:
          type: text
          value: Watched - Episodes

Expected behavior

• Absence of [WRN] [72] MediaBrowser.Controller.Entities.BaseItem: Unable to find linked item at path... entries in Jellyfin logs
• Hopefully cores on the Jellyfin server not running around 100% for long periods of time

Screenshots

Search for media listed in Jellyfin Logs:

Device:

• OS: Docker on Debian 12
• Version: 3.13.0
• Server: Jellyfin

Debug logs

maintainerr-2026-06-03.log

jellyfin-20260603.zip

Additional context
The goal of the suspect rule is to make a “sticky” list: items can be added by their criteria but not removed if that criteria changes.

People were clicking on everything in the Leaving Soon list to make sure they had watched the media before it was deleted.

This resulted in media playback status being set to Unwatched.

Stopping the rule by restarting maintanerr also stops the logs in Jellyfin about Unable to find linked item at path and coincides with lower CPU usage on the Jellyfin host.

Stopping the rule via the UI button did not result in the suspect rule being cleared from the bottom-left of the UI where the currently processing rule is displayed.