Symptom first, fix second
Trex IPTV refund requests: diagnose first, then escalate
A good number of the Trex IPTV requests that start out as refunds end as a host switch nobody had suggested, and most of the rest move faster because the person filing arrived with dates and results attached. This page is about telling those two apart before you lose a week to the wrong one.
Where the request actually goes
#Refunds are handled where the order was placed, not in a technical thread and not by anyone moderating here. Nobody on this side can see an order, so raise it at https://trexiptv.click when you are ready. We keep the forum entirely out of that process on purpose, so the advice you get in a fault thread is never shaped by what it might cost somebody.
Run these four checks first
#Switch to a different mirror host and replay the channel that failed. Test the same credentials in VLC on a laptop to take the TV out of the equation. Confirm that nobody else in the building has the same line open. Check whether the line has simply reached its expiry date. Each of these takes minutes and each one changes the conversation entirely. Running them on the right device matters as much as running them.
Faults that look terminal and are not
#Persistent stutter on busy channels is usually load on one host. A MAG that suddenly shows nothing is usually a binding pointed at hardware that changed. A dead-looking line on every device at once is usually authentication rather than streaming. None of those are unrecoverable and all of them get misfiled as a broken product. What each error wording really means sorts most of them.
What troubleshooting will never change
#Some things genuinely will not be fixed, and pretending otherwise wastes your time. A channel that the regional package behind your credentials does not carry is not going to appear, on any host, ever. A line will run one stream and not two. If your expectation was one of those, no amount of testing changes the outcome and you are better off escalating immediately. The one line, one stream rule is the usual culprit.
What evidence to bring
#Dates and times of failures, the hosts you tried, the devices you tested, the exact channel names, and the result of the VLC test. A request built from that is specific and checkable. A request that says it never worked properly is neither, and it will come back to you as a list of questions.
Questions
#My line buffers constantly. Is that grounds for escalation?
Only after a host switch fails to change anything. Constant buffering on one host and clean playback on another is a load pattern with a known remedy, and it will be the first thing anyone asks you about.
The channels I wanted are not in my line-up.
Establish that first, precisely, by naming the channels and confirming they are absent from a search inside the app rather than just missing from a category you browsed. Carriage follows the regional package the credentials were issued against, and that is an escalation rather than a fix.
Can somebody here check my order?
No. Nobody on the forum has access to orders, and anyone claiming otherwise in a thread should be reported. Order questions belong on the shop.
How long should I spend testing before I escalate?
One evening, done properly. The four checks take well under an hour between them, and a request that lists what you ruled out is handled faster than one filed within an hour of the first stutter.
The fault is real but intermittent. Does that still count?
Yes, if you can show the pattern. Timestamps across several days with the host and device against each one are stronger than a continuous fault described from memory with no times attached.
Can a thread here speed a request up?
Not directly, since nobody moderating has any visibility into orders. What a thread can do is establish exactly what the fault is, which turns a vague request into a specific one before you file it.
Still stuck after all that?
Send the channel, the device and the app you are using and we will look at the line itself.