Trex IPTV
Symptom first, fix second

Running lines for other people

If you look after credentials for more than a handful of screens, the failure modes change shape. The technical rules are identical, but record keeping becomes the thing that saves or ruins your week. These are the habits that separate a smooth operation from a chaotic one.

One line per screen, no exceptions

The single most expensive mistake at volume is quietly handing the same credentials to two people who never seem to watch at the same time. They will, eventually, usually during a final. Each of them then reports a fault that neither you nor anyone here can reproduce, because the cause is the other person. Concurrency is enforced per line, so plan on the basis that it will be tested.

Keep a MAC register

For every MAG box you place, record the MAC address on the sticker next to the line it is bound to and the date it went out. When a customer replaces a box, you want both addresses in one message rather than a fortnight of back and forth trying to work out which unit is which. Photograph the sticker at the point of installation. It takes four seconds and it will save you an afternoon within the year.

Teach the host switch before you need it

Most of the calls you will take are buffering, and most of those clear by pointing the player at a different mirror host. Write the alternate host on the same card as the credentials and show the customer once, on their own remote, while you are standing there. Every customer who can do this themselves is a call you do not take during a live match.

Label the two formats distinctly

Half of all handover confusion is an M3U playlist link being pasted into a field expecting a portal, or the reverse. Use different labels, different colored cards, whatever separates them visually. Never send both strings in the same message body without a line break and a heading, because people scroll and grab the wrong one.

What is outside your control

You cannot re-bind a MAC, reissue credentials, or lift a concurrency limit yourself, and neither can we from a forum thread. Those are source-side actions and they need to go to support with the specifics attached. Being clear with your own customers about that boundary is better than promising a fix you have to walk back.

Commercial questions go elsewhere

This forum is a technical space and we keep it that way on purpose. Anything about arrangements, terms, or what things cost should go to support directly rather than into a thread, where it will be moved. Nothing in here quotes figures and nobody in here is authorized to negotiate.

Questions

Can I move a customer from MAG to a Fire Stick?

The line itself is portable in principle, but the delivery differs: MAG uses a portal bound to a MAC, while a stick takes an Xtream login or a playlist URL. Ask support what that line supports before you promise the customer a switch.

A customer says every channel buffers on every host.

Get them to test one channel in VLC on a laptop on the same network. If it is clean there, the problem is the device or the wiring in that house, not the line, and no further host testing will help.

How do I prove a fault is on my side or not?

Run the same credentials on your own device on a different network. Two locations, one line, two results tells you everything. Include both results when you report it.

A customer moved house and nothing works on the same box.

New router, new wiring, same box. Run the two-location test before you touch the line at all, and check whether the box is now on Wi-Fi where it used to be wired. Moves produce network faults far more often than they produce line faults.

A customer refuses to run any test and insists it is the line.

Run it yourself with their credentials from your own network, at the hour they say it fails. Either you reproduce it, which gives you a real report, or you do not, which tells you the fault lives in their house and ends the argument politely.

Still stuck after all that?

Send the channel, the device and the app you are using and we will look at the line itself.