Identify the expected change
Record the installed release and the version you expected to receive. Distinguish a minor maintenance update from a new major series. Use the current official download information, since example version numbers inside the wiki illustrate the method rather than identify today’s recommended release.
For a hypothetical setup, a person may see a new major release announcement and expect the normal background maintenance process to install it. The documented boundary means that expectation should be checked before repeatedly restarting the device or changing DNS settings.
Plan the deliberate migration
LibreELEC explains that major changes involve Kodi add-ons and user-experience differences. Inventory the essential authorised add-ons and sources, preserve configuration and check the supported target for the exact hardware. A new release existing for one board does not establish the same path for every box.
Choose a time when the household can tolerate investigation if an add-on needs attention. Keep a working fallback and a private record of the current version. Do not force a historical example download URL into an update command merely to make the version number change.
Check the actual failure category
If a supported minor update also fails, record its message and whether the file download begins. That is a different observation from a deliberate major update not happening automatically. Keep the settings add-on’s chosen channel and release with the report.
For support, include hardware, current and desired version, update method and exact outcome. Avoid factory resetting a working player to address a policy boundary documented by the publisher. This article explains the current published distinction; it does not run an update, guarantee a rollback path or claim that every add-on remains compatible afterward.