The media server getter services correctly need backend-specific logic, because different servers expose different APIs, identifiers, metadata shapes, and watch/collection behavior. That part should remain separate.

The current problem is that rule-property evaluation still contains a large amount of overlapping logic across backend-specific getters. This makes behavior harder to maintain and increases the risk that future fixes or features land in one backend implementation but not another.

Why this matters:

• new rule properties often require touching multiple getter implementations
• behavior can drift between media server backends over time
• bug fixes in one implementation are easy to miss in another
• the current structure makes parity testing and future extensions harder than necessary

Suggested scope:

• keep backend-specific data fetching and normalization inside backend-specific adapters/getters
• extract shared rule-property evaluation helpers for behaviors that should remain semantically consistent across backends
• leave only genuinely backend-specific property handling in the individual getter services
• add parity-focused tests for overlapping properties to reduce future divergence risk

This would reduce technical debt in the rule evaluation layer while preserving the backend-specific logic required by different media servers.