Build a Plain-English Taxonomy of Playback Error Messages
Group messages by the stage they appear to reference—availability, session or authorization, permission, network resolution or transfer, media capability, media processing, output, device resources, or unknown—while preserving the exact official code. A category routes the next question; it does not establish the cause.
In short: Group messages by the stage they appear to reference—availability, session or authorization, permission, network resolution or transfer, media capability, media processing, output, device resources, or unknown—while preserving the exact official code. A category routes the next question; it does not establish the cause.
User-facing wording is designed for readability and may combine several internal conditions. Keep the original text beside the category.
Category 1: availability
Messages such as “unavailable,” “not found,” or “try later” may concern one title, version, source, region, account, or temporary source state. Record scope, time, status notice, and comparison titles.
Separate temporary and persistent unavailability before repeated retries.
Category 2: session and authorization
Messages may mention expiry, sign-in, authorization, device limit, or access. Record account-safe state, clock, phase, source, device, and whether other authorised titles work. Do not publish session tokens or cookies.
Do not assume a session message means the password is wrong.
Category 3: permission and policy
Local-network access, storage, background activity, parental controls, managed-device policy, source entitlement, or region rules may affect playback. Verify official requirements and authorization; never bypass a policy as a diagnostic shortcut.
Keep billing and legal questions with the relevant official support team.
Category 4: network resolution or transfer
Messages may refer to offline state, timeout, connection, or server reachability. Record active path, endpoint scope, name resolution, throughput, delay variation, loss, and time. A generic network message does not prove Wi-Fi or provider fault.
RFC 9110 defines HTTP semantics, but do not map app wording to a specific status without validated evidence.
Original evidence: layer-and-language taxonomy
| Exact wording/code | Phase | Plain category | Scope | Required evidence | Safe next check | Official definition |
|---|---|---|---|---|---|---|
| Verbatim | Startup/midplay | Availability/session/etc. | Title/device/path | Context | One comparison | Link/version |
| Verbatim | Seek/track change | Category | Scope | Context | One comparison | Verified/unknown |
Add separate columns for privacy risk and confidence. Never overwrite the original wording with the category.
Category 5: media capability
“Unsupported format,” “cannot play,” or capability messages may concern container, codec, profile, resolution, frame rate, dynamic range, audio, encryption, output, or the combination. W3C Media Capabilities provides contextual queries in supported web implementations.
The unsupported-media guide builds a version and device matrix.
Category 6: media processing
Parse, append, decode, synchronization, and seek failures may occur after media is found and authorized. W3C Media Source Extensions defines coded-media processing for compatible implementations, but native players can use other paths.
Do not translate a stall into “decoder error” without an official code definition.
Category 7: output
Black screen with audio, picture without sound, protected-output messages, or remote-playback failure can involve display, receiver, cable, audio route, permissions, or capability. Record local versus external output and safe-volume state.
Output failures should remain distinct from network delivery unless evidence links them.
Category 8: device resource or app state
Messages may mention storage, memory, update, temperature, background limits, or internal app state. Record official warnings and versions. Avoid service menus, unofficial firmware, and intrusive monitors.
An “unknown error” belongs in the unknown category until official support provides a definition.
Use scope as the second axis
Within each category, mark one title, one source, one device, one network, one time window, or global. Read the error before fixing it and compare one axis.
Scope often routes support more effectively than the friendly wording alone.
Keep Norva boundaries accurate
Norva organises and plays compatible authorised sources. Current Norva messages and code meanings must be verified from official, version-specific documentation. It cannot redefine a source's availability, authorization, or media errors.
Frequently asked questions
Can one message belong to two categories?
Yes. Preserve a primary and secondary candidate category with uncertainty until official evidence clarifies it.
Should categories be converted into automatic fixes?
No. They route safe questions; exact causes and recovery remain version and context dependent.
Is “unknown” a useful category?
Yes. It prevents invented meaning and signals that official definition or more evidence is required.
Your next step
Explore Norva's playback features