Manual

Provider TV stutters

Blocks in the picture, or a network that floods the moment the TV comes on.

Two complaints that belong together. The first: the picture stutters, breaks into blocks, or a channel will not start while the internet is perfectly fine. The second: the moment the TV goes on the whole network slows down, Wi-Fi included, for people who are not watching anything.

Both come from the same corner. With most providers, television arrives as multicast: one stream of packets, copied through the network to everyone who asks for it. If the asking does not work you get no picture. If the filtering does not work everybody gets everything.

What it is not: TV delivered through an app (catch-up services, streaming platforms, some providers) is ordinary TCP traffic and has nothing to do with this chapter. If that stutters, read Everything is slow at peak hours.

The quick checks, in order

  1. Does your provider deliver TV as multicast? That is the first question, and the answer differs per provider and sometimes per region. If the set-top box gets its picture over its own VLAN, that VLAN belongs in the router as a second uplink.
  2. Is the IGMP proxy running? /routing igmp-proxy interface print. A good answer shows two lines: the uplink with upstream=yes and the LAN side without it. An empty list means nothing was generated for IPTV.
  3. Does the stream arrive? /interface monitor-traffic interface=ether1 on the WAN port while the TV is on. A television channel is easily 8 to 20 Mbit/s. If you do not see it, nothing is coming in and there is no point looking further inside the network.
  4. Is the multicast being blocked? /ip firewall filter print stats and /ip firewall raw print stats. Look for a drop rule whose counter rises as you select a channel. The bogon rules are the usual suspect here, because 224.0.0.0/4 is on that list.
  5. Is IGMP snooping on? /interface bridge print and look at igmp-snooping. Set to no while your network floods, and you have found the second complaint.
  6. How much traffic reaches a port with no TV on it? /interface monitor-traffic interface=ether4 on any port. A few Mbit/s of background noise is normal; 20 Mbit/s towards a port with only a laptop is the stream being sent everywhere.

The usual causes, most common first

No IGMP proxy, so no picture

The router has to accept the provider's multicast and pass it to the LAN. Without that proxy nothing gets past the router. This is the simplest case: it does not work, and it never did.

The firewall throws the stream away

The standard bogon rules block 224.0.0.0/4, which is exactly the multicast range your television lives in. With IPTV, that one entry has to go and IGMP plus the multicast from WAN have to be let in. Those are three changes that belong together: the bogon list, the input chain for IGMP itself, and the forward chain for the stream.

No IGMP snooping: the network floods

Without snooping the bridge does not know who wants the stream, so it sends it to every port, Wi-Fi included. Two televisions on and your whole wireless network is occupied by a picture nobody there is watching. This is the second complaint from the introduction, and switching snooping on is the entire fix.

The TV is on Wi-Fi

Multicast over Wi-Fi is transmitted at the lowest rate so that every client can receive it. That is the worst possible combination: slow and addressed to everyone at once. A set-top box belongs on a cable.

The TV is in a different VLAN from the uplink that carries the stream

If your provider uses a separate TV VLAN, that VLAN has to run all the way to the box, and the proxy has to sit on the right uplink.

What the configurator does about it

  • The WAN section has the toggle Provider IPTV over multicast (IGMP proxy). That is the control. Its help text says exactly what it does: the router becomes an IGMP proxy, multicast arrives on the uplink and is passed to the LAN, and without it multicast from WAN is dropped by the bogon rules. If your provider delivers TV on its own VLAN, you add that as a second uplink and pick it there.
  • The script then writes /routing igmp-proxy interface with the uplink as upstream and the LAN side as downstream. The upstream gets alternative-subnets=0.0.0.0/0, because the stream comes from somewhere inside the provider network rather than from the WAN subnet itself; without it the proxy ignores the sender.
  • The firewall adapts: with IPTV on, the multicast entry leaves the bogon list, a rule accepting IGMP is added to the input chain, and a rule accepting multicast from WAN is added to the forward chain.
  • If IGMP snooping is not on for the bridge, the tool says so immediately: turn on IGMP snooping on the bridge, otherwise the TV stream is flooded to every port and swamps the network. The toggle itself is in the Bridge & ports section.
  • If the Firewall section is switched off, the tool warns that IPTV needs firewall rules to let multicast in from WAN.
  • If no uplink is chosen or no WAN is defined, that is an error: nothing is generated for IPTV until the field is filled in.

The honest limits

The tool does not know what your provider does. Whether television is multicast where you live, which VLAN it uses and whether it needs a fixed priority tag is information from your provider, not from this program. The provider presets cover the known cases, but a regional variation or a new subscription can fall outside them. The box itself can also be the obstacle: many decoders want a DHCP option or a specific provider DNS name, and no multicast setting helps with that. And if your uplink is already full in the evening, the TV stream will not win that race.

Read on: Recipe: IPTV, WAN and internet and Provider presets.

Want to try it right away? Open the configurator