The Complete Category and Metadata Troubleshooting Handbook
A disciplined category and metadata investigation separates source observations, visible item identity, view controls, device context, timing, and presentation before any correction.
In short: Describe one visible category or metadata symptom, preserve its first timestamp, and freeze the account, profile, source selection, filters, grouping, device, and application version. For a small authorized sample, compare source data, item and version identity, category membership, and each displayed field independently. Change one reversible view control at a time, avoid source edits, and send support redacted observations rather than an invented explanation.
Categories and metadata help people find and recognize media, but a visible mismatch can originate in source data, item identity, view context, timing, or presentation. The interface alone does not reveal an internal rule, so evidence must remain layered.
Name the smallest symptom
Choose one observable result: an item is uncategorized, two category labels look duplicated, an empty category remains, category order changes, a title or year differs, artwork is absent, a synopsis appears old, a rating is missing, or a badge disagrees with the visible track list. Avoid “metadata is broken,” which hides useful distinctions.
Freeze the viewing context
Record the Norva account, active profile, enabled source labels, availability, category, year, rating, audio, subtitles, search query, sorting, grouping, device, operating system, application version, network, and timestamp. A different filter or profile can create a new view without changing source data.
The import and sync handbook covers upstream operation states when the issue began during import.
Separate six evidence layers
Keep these observations distinct:
- What the authorized source currently exposes.
- Which logical item or version is being compared.
- Which category or metadata field appears in Norva.
- Which view controls affect visibility or presentation.
- Which device, version, and time produced the screen.
- Which edits, imports, refreshes, or user actions occurred.
A correlation between layers is useful, but it is not a verified product rule.
Build a minimal sample
Choose up to three entries: one affected item, one unaffected control from the same context, and one alternate source or version when relevant. Assign privacy-safe sample codes. Record visible title, year, media type, source, season, episode, duration, version, language cues, artwork, category, and the field under investigation.
Do not export the household catalog or complete viewing history.
Verify the source observation
Through the provider's official authorized route, record the same field and item cues with a timestamp. Note whether the value is absent, different, or changed recently. Source data is one input observation; it does not by itself establish what Norva must display or how it maps fields.
Confirm item and version identity
Same-title entries may represent different years, cuts, episodes, source versions, languages, or durations. Compare ordinary interface cues before treating values as contradictory. The runtime comparison shows why identity matters.
Compare fields independently
Record title, year, genre, synopsis, rating, poster, runtime, audio badge, subtitle badge, and track list as separate rows. One correct field does not prove every field has the same source or update state. Missing artwork is not missing media, and a badge is not the same observation as a playback track list.
Use the poster checklist and localized-title comparison for focused branches.
Change one reversible view control
Remove one visible filter, switch between category and search, or check another supported trusted device while keeping every other context stable. Return to baseline before the next comparison. Do not clear application data, reinstall, remove the source, or edit source metadata as first steps.
Preserve the timeline
Record the source value confirmation, import or refresh request, visible state, first mismatch, every correction attempt, and current observation. Use only timing guidance published by current Norva support. Otherwise report elapsed time without inventing an update promise.
Treat corrections as owned changes
Before editing anything, identify whether the household controls the source field and whether the provider supports a correction. Record who made the change, where, when, and what value existed before. Do not promise that an edit will persist through future source updates or refreshes.
The correction ownership guide helps when an edit later changes again.
Escalate a compact evidence pack
Send support one symptom, the stable context, source observation, visible item identity, affected field, timeline, up to three samples, controlled comparison, and action log. Remove credentials, private source addresses, complete catalogs, and unrelated profile data. The metadata evidence pack provides a reusable structure.
Original evidence: category and metadata matrix
| Layer | Affected sample | Control sample | Observation time |
|---|---|---|---|
| Source field | |||
| Item and version identity | |||
| Category membership | |||
| Norva field or badge | |||
| Filters and grouping | |||
| Device and app version | |||
| Action history |
Common mistakes and limitations
- Treating similar titles as identical versions.
- Comparing different profiles, filters, or devices.
- Editing the source before preserving its original value.
- Assuming one field reveals Norva's mapping logic.
- Repeating imports or refreshes without a timeline.
- Sending complete catalogs or credentials to support.
Frequently asked questions
Which value should be treated as authoritative?
Record each authoritative system for its own observation. Do not infer that one visible value automatically controls every Norva field.
Should I correct source metadata immediately?
Preserve the baseline first and confirm authorization and ownership. An edit changes the input and may hide the original mismatch.
How many samples should I document?
Use the smallest representative set, commonly one affected item, one control, and one alternate version when identity is uncertain.