Skip to content

[BUG] Can't configure separate stall rule for 0% progress #541

@freddyheppell

Description

@freddyheppell

Duplicate check

  • I have searched for existing issues and confirmed this is not a duplicate.

Before submitting a bug report, I have:

  • Reviewed the documentation.
  • Ensured I am using ghcr.io/cleanuparr/cleanuparr docker repository.
  • Ensured I am using the latest version.
  • Enabled verbose logging.

What is the behavior?

I had a download on a private tracker fail to start due to the tracker being down, but it wasn't getting strikes. In the logs I can see the message:

skip | multiple StallRule rules matched | [file]
Job QueueCleaner
Instance [instance]
Job Run 019d4d9e-1920-78fa-8c3b-e863dc8898d8

(These are the only logs for this job run - I didn't actually get to enable verbose logging since the download was cleaned once I disabled a rule)

The download was from a torrent file rather than a magnet link, which I assume is why it didn't count as stuck fetching metadata?

I wanted to configure the rules so that:

  1. public tracker downloads at any progress can be deleted
  2. private tracker downloads at 0% (they haven't started, like in this case) can be deleted
  3. private tracker downloads >0% (they have started) can't be deleted

I attempted to configure this with 3 rules:

  1. Public, 0-100%
  2. Private, 0-0%, Delete private from client enabled
  3. Private, 0-100%, Delete private from client disabled

In this case, the download matches rules 2 and 3, triggering the multiple match skip.

If I set rule 3 to 1-100%, it warns there's a gap 0-1% for private. Incidentally it doesn't warn that there's overlapping rules until it appears in the logs, it might be useful if the settings page warned about this like it does for gaps.

Am I missing a way of configuring the desired behaviour? Or is there something wrong with my planned rules, which is why it's not supported?

A possible fix for this would be to make the lower bound exclusive (so 50-100% is actually >50%, ≤100%), and add a checkbox to match downloads that haven't started (progress is exactly 0%). I think that changing the lower bound to be exclusive would have minimal impact on existing rules, since it's unlikely that download progress will ever fall exactly on the threshold.

Which operating system do you use?

Linux

What type of deployment do you use?

Docker container

Relevant log output

Anything else?

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions