What actually happens when a MAG line is made
Three things have to line up and they are created in a fixed order. A line record is built with a term, a package and an expiry. That record is bound to one MAC address. The address you point the box at then answers requests from that MAC with a channel list. Nothing about the box is configured at our end; the box is only ever recognized. This is why a MAG is the one delivery format where a typing mistake made at order time cannot be fixed on the device: the mistake is in the binding, and the binding is one field away from being right at source.
The MAC on the sticker is not always the MAC in use
Read it off the underside of the unit and it will be right most of the time, but there are two ways to be wrong. Boxes with both wired and wireless interfaces carry two addresses and some print only one on the label. And a unit that has been repaired, reflashed or bought second-hand can report something different from what is glued to it. The address the box believes in is the one under its own system information screen, so quote that one, and quote it with the colons in. If the two disagree, say so in the thread rather than choosing between them.
Type the portal address exactly as it was issued
The address goes in as sent, character for character, including whatever comes after the domain. Do not append a path on a guess and do not strip one that looks decorative to you: the shape of the address depends on how the portal in front of it is deployed and both a bare host and a host with a trailing path are normal. Most first-boot failures in this category are a missing or invented trailing character, a leading www that was never there, or a capital letter contributed by the on-screen keyboard. Save, then power cycle the box properly rather than backing out of the menu.
Where a MAG boot actually stalls
The sequence is loader, network, portal, line-up, and each stall means something different. A box that never leaves the loader has a firmware or hardware problem and no portal address will move it. A box that shows a network error before any portal text is a DHCP or cable problem on your side of the wall. A box that reaches a portal screen and sits on a spinner has connected to something and is waiting for an answer, which points at the address or the host. A box that loads the portal and shows an empty list has reached us, been recognized, and found nothing to authenticate, which is a line question rather than a hardware one. Say which of those four you are looking at and any answer you get will be worth reading.
The clock is a real cause, not folklore
Set-top hardware of this generation keeps time badly across a power cut, and a box whose date is months out can be refused by the thing it is talking to without either side explaining why. It is cheap to eliminate. Open the box settings, confirm the time zone and the current date before you look at anything else, and set the clock to update over the network if the option is there. A refusal that clears the moment the date is corrected has saved more evenings on this forum than any host swap.
Network settings, in the order worth testing
Start with a cable if you have one, because wireless on these boxes is the weakest part of them and a marginal signal produces stalls that look exactly like portal faults. Leave the address assignment on automatic unless someone had a reason to change it. If a previous owner or a previous evening left a fixed address and a hand-typed DNS behind, that is a strong suspect: a box with a stale gateway will resolve nothing and report it as a portal failure. Put everything back to automatic, reboot, and only then decide whether the network is the story.
What a factory reset fixes and what it cannot
It clears the portal address, the network configuration and any half-finished profile left over from an earlier attempt, which makes it the right move when you have edited so many fields that you no longer know which ones you changed. What it does not touch is the binding, because the binding does not live in the box. A reset will not make an unbound MAC recognized, will not revive an expired term, and will not undo a MAC typed wrongly on an order. Reset when the box is confused. Ask at source when the box is clear and the answer is still no.
Emulators are not MAG boxes, except when they are
Several Android applications present themselves as MAG hardware and take a portal address and a MAC in exactly the same two fields. They work on the same principle, and a line bound to the MAC that the application generates behaves the way a real box behaves. The trap is that the generated MAC can change: reinstall the app, clear its data, or restore the device from a backup and the identity it presents may no longer be the one on file. If you are running an emulator, write its MAC down somewhere off the device the day it starts working.
Replacing a box without losing the term
A new box has a new address and the existing binding points at the old one, so the new unit will reach the portal and be told nothing. The remaining months are not lost and nothing has to be bought again. Send both addresses in one message, old and new, with the order reference, and ask for the binding to be moved. Threads that arrive with only the new address take two extra exchanges to resolve because the old one is what identifies which line is yours. Keep the old box unplugged while this happens so nothing is ambiguous.
Posting a MAG fault that gets answered first time
Give the model number, the address the box reports under system information, the exact wording on screen, and the stage in the boot sequence where it stopped. Add whether it has ever worked, and if so what changed between then and now, including power cuts, firmware updates and house moves. That is five lines and it usually collapses the whole thread into a single reply. [Why the exact wording matters more than a paraphrase](/error-messages.php) is set out message by message, and [anything involving the binding](/contact.php) has to go to support in the end.
