A good number of the 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Send the channel, the device and the app you are using and we will look at the line itself.
