Miguel Palhas
a5b3680746
`resolution_pref` only gated eligibility, so every release was scored against its own resolution's size band and a 23 GB 4K lost to an at-target 1080p. Each step up the list is now worth `resolution_step` points, seeded at 300: five gibibytes of 4K overshoot, so a 4K up to 27 GB wins and a bloated one still does not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
19 lines
1.1 KiB
SQL
19 lines
1.1 KiB
SQL
-- §5.5 cross-resolution ranking, issue #113. The size term scores a release
|
|
-- against the band for its own resolution, so it says nothing about how
|
|
-- resolutions rank against each other: an at-target 1080p and an at-target
|
|
-- 4K both score `size_at_target`, and a 4K a couple of gibibytes over target
|
|
-- lost to a 1080p that was merely on target. `resolution_pref` being an
|
|
-- ordered list already implies a preference; this is the weight that makes
|
|
-- the scorer honour it.
|
|
--
|
|
-- The last entry of `resolution_pref` is worth nothing and each earlier one
|
|
-- `resolution_step` points more. 300 is chosen against the seeded 4K band
|
|
-- (target 22 GiB, 60 points per gibibyte over): five gibibytes of overshoot,
|
|
-- so a 4K up to 27 GiB beats an at-target 1080p and a bloated 4K past that
|
|
-- does not. Below target the same arithmetic asks a 4K to be within about
|
|
-- four gibibytes of its target to win, which keeps an 8 GiB 4K that looks
|
|
-- like mud from beating a good 1080p.
|
|
UPDATE policies
|
|
SET score_weights = json_set(score_weights, '$.resolution_step', 300),
|
|
updated_at = strftime('%Y-%m-%dT%H:%M:%fZ', 'now');
|