The Complete Guide to Filtering a Personal Media Library
Effective filtering starts with the household decision, maps each requirement to a trustworthy field, applies one condition at a time, and preserves a visible reset path.
In short: State the viewing decision, separate non-negotiable requirements from preferences, and map each requirement to a metadata field you trust. Apply one filter at a time from broad, reliable constraints to narrower or less complete ones. Watch the result count and active-state summary, verify representative records, and remove the weakest or latest condition first when the set becomes empty.
Filters do not improve metadata; they expose the subset whose metadata matches each condition. A valid choice can disappear when a field is missing, stale, version-specific, or interpreted differently from the label.
Begin with the viewing decision
Write the question in one sentence:
- “Show films currently available from our connected sources.”
- “Find a favourite with French audio and English subtitles.”
- “Choose a family film released after 2015.”
- “Browse any series in this category, then put recent items first.”
The sentence determines which controls are filters, which are preferences, and which are sorting.
Build the requirement-to-filter contract
| Requirement | Must/prefer | Field/control | Value meaning | Metadata confidence | Expected exclusion | Control item |
|---|---|---|---|---|---|---|
For every row, ask whether the field applies to the work, one version, or the current source. “French audio” is version-specific; “favourite” may be profile-specific; “available” is time-sensitive.
Separate must-haves from preferences
Apply true requirements first:
- current availability when playback now is essential;
- media type when films and episodes must not mix;
- required audio or subtitle choice;
- source when authorisation or device access makes it necessary.
Use sorting or visual comparison for preferences such as newest first or highest-rated, where no candidate must be excluded.
Check field reliability before filtering
Use known positive and negative controls:
| Filter | Known matching record | Known non-matching record | Expected | Actual |
|---|---|---|---|---|
If a known matching item disappears, the field, version scope, or filter semantics need investigation. Do not build a multi-filter recipe on an unverified condition.
The Library of Congress Basic Search guide explains that facets can narrow a large catalogue, while records lacking the faceted metadata may disappear. That is a core limitation of metadata-driven filtering.
Apply broad to narrow
A useful default order is:
- source or current availability, only when required;
- film, series, episode, or special type;
- broad category;
- year or date range;
- audio or subtitle requirements;
- favourite or profile-specific context;
- narrow tags and secondary preferences.
This order is not universal. Choose the first filter with the best combination of requirement strength, metadata reliability, and expected reduction. Follow the broad-to-narrow method one step at a time.
Read every result transition
After each filter, record:
- active filter and displayed label;
- result count before and after;
- known control still present;
- any option counts that changed;
- whether no-value records were excluded;
- whether sort or query context remained.
Unexpected collapse is evidence. Remove the new condition and investigate rather than adding another filter.
Understand combination logic
Many filter sets use AND across different fields: a candidate must be a favourite and currently available. Within one field, multiple selected values may use OR: French or English audio. But implementations vary.
Confirm whether selecting several categories broadens or narrows the set. Labels such as “Any,” “All,” “Only,” “Exclude,” and “Hide unavailable” must be interpreted literally and tested.
Distinguish filtering from sorting
Filtering removes candidates. Sorting keeps candidates and changes their order. Use the filtering-versus-sorting guide when the set is already acceptable and the goal is prioritisation.
Recover from empty results
Use the empty-results workflow: capture state, remove the last filter, then relax the least reliable or least necessary requirement. Clear hidden limits and run a known control. Do not reset everything before learning which condition caused the conflict.
Preserve and reset context intentionally
A useful reset returns to a known baseline without losing the query, category, or scroll position that still matters. Record which state should persist between sessions and which should not. Profile-specific filters should not silently become household-wide assumptions.
Norva can organise and filter compatible authorised sources, but available fields, metadata completeness, and version-level tracks depend on source data. Norva does not provide a media catalogue.
Common mistakes and limitations
- Treating preferences as must-have filters.
- Applying several conditions before inspecting the baseline.
- Filtering a work-level card by version-level language without verification.
- Forgetting hidden or persisted filters.
- Mistaking sort for filtering.
- Assuming empty results prove no matching media exists.
Filter results are only as complete as the underlying metadata and the current source state.
Frequently asked questions
How many filters should I use?
Use the fewest that express the real requirements. Stop when the result set is manageable and every remaining candidate is plausible.
Should favourite status be filtered first?
Only when the choice must come from favourites. Otherwise, it can hide useful catalogue-wide candidates too early.
Why does adding a language filter remove a known title?
The track may belong to another version, the metadata may be missing, or the filter may use a different scope. Open details and audit the actual selectable track.