When a project film cannot load, an endless spinner gives the visitor no useful decision to make. Ask the website supplier to show the failure state before release. The page should explain the immediate problem plainly, offer a sensible next action and preserve access to useful project information where possible.
MDN's MediaError reference distinguishes general error categories from diagnostic messages. Those technical details can help the implementation team investigate, but they are not automatically good wording for a visitor. Commission both an understandable message and an appropriate diagnostic record.
Separate waiting from failure
Ask what causes the player to keep waiting, show a retry option or report that playback is unavailable. You do not need to prescribe the code or an arbitrary timeout. You do need a demonstrated rule that prevents the interface from suggesting progress indefinitely when it has no viable route forward.
The wording should avoid unsupported certainty. “Your connection is too slow” may blame the viewer when the media address is wrong or access has expired. A neutral description of the observed failure, with an action the visitor can take, is more useful than a diagnosis the player cannot substantiate.
If retry is offered, test it. Confirm whether it reuses the same failed state, starts a fresh request or returns the viewer to the beginning. After a mid-film interruption, discuss whether retaining the position is appropriate and feasible in the supported player.
Provide information beyond the failed component
A transcript, project summary or contact route should remain reachable if it does not depend on the same failed media request. Name each alternative accurately. A transcript can support reading the explanation; a contact form can request help; neither should be presented as successful video playback.
Keep essential error information outside a control that cannot be opened. If the player fails before its settings become available, hiding the only help route in that menu defeats the purpose. Review the state with keyboard and assistive technology as part of the agreed evaluation.
Ask the website team to capture enough information for investigation without exposing internal details or collecting unnecessary personal data. A page identifier, time of occurrence and broad failure category may be more useful to support than a screenshot of a generic spinning icon. The responsible team should define the appropriate diagnostic practice.
A hypothetical removed asset
Suppose a builder replaces a hosted file but one project page still requests the removed address. The player displays its loading animation indefinitely. Marketing initially asks the producer to export the film again.
A failure test reveals the stale request. The website owner repairs the address and demonstrates the recovery state for a deliberately unavailable test asset. The buyer can now distinguish a correct film from a broken delivery reference and knows what future visitors will see if another failure occurs.
Include recovery in release acceptance
Request one controlled failure demonstration in a safe test environment. The goal is to observe the planned response, not to disrupt the public site. Record the retry behaviour and the available alternatives alongside the successful playback check.
Bring the intended film and fallback assets to Live Images when defining production scope. Ask the website supplier to own error handling and diagnostics, and confirm suitability before assuming either role is included in the film commission.
Prepared with AI assistance for Live Images. Planning guidance is general; suitability and production scope must be agreed for your project.