Hoi @Roel_Beijnes . Welkom op het forum.

Vervelend dat je itv ervaring niet vlekkeloos gaat. Ik ondersteun geen eigen hardware maar ik weet wel dat er genoeg gebruikers zijn die hun itv via bijvoorbeeld ubiquity feilloos aan de praat hebben gekregen. Er is dus vast een oplossing. Er zijn op het forum een aantal mensen die hier veel over weten. Je kunt het via google wel achterhalen door ubiquity + kpn + itv te zoeken. 

Hoi @Erwin_ , Bedankt voor jouw reactie!

Uiteraard heb ik de benodigde informatie al gevonden via de forums en sommige blogposts. Bij KPN heb ik allerlei instellingen nodig, zoals IGMP snooping. Hierdoor maakt KPN het onnodig lastig voor mensen om een simpele switch te gebruiken. Ik begrijp het gebruik van VLAN's, echter ik wil zonder VLAN. IMGP snooping en allerlei routing instellingen werken.
 

De voordeel van TV over ethernet is een kabel voor TV en internet. Het dient te zijn Internet = TV signaal.
Bij T-Mobile hebben ze minder instellingen nodig.

Ik snap het.  Deze technische keuzes zijn natuurlijk niet bedacht om de klant te pesten. Hier zijn legio redenen voor die met kwaliteit (en potentieel misbruik) van het signaal te maken hebben. 

Als je er voor kiest om eigen hardware te gebruiken zit je dus toch vast aan bepaalde configuraties en dient de apparatuur bepaalde functies te ondersteunen. Dat gaan jij en ik helaas niet veranderen. Laat ik daar geen valse verwachtingen over creëren.  

Dat begrijp ik ook, maar waar kan ik een klacht indienen over dit onderwerp? (Niet voor jou hoor! )

Als niemand klaagt of zich uitspreekt, blijft dit een probleem. 

Ook met apparatuur van KPN zou ik problemen hebben. Hoe krijg ik TV signaal op de zolder? moet ik voor elke tv signaal een eigen ethernet kabel aanleggen. Helaas werkt dat niet voor elke huishouden. 

ps: de reden omtrent misbruik van signaal vind ik onzin. Je kunt werken met autenticatie encryption, certificaten en allerlei andere methodes. Je kunt zelf simpel aangeven dat TV signaal toegestaan is vanuit adress A.

Dat KPN voor live televisie kijken IGMP multicasting gebruikt is zo ongeveer een vereiste om kwalitatief hoogwaardige TV streams te kunnen distribueren zonder dat het netwerk enorm belast wordt. M.b.v. IGMP multicasting hoeft een TV stream op elke lijn van het netwerk maar één keer verstuurd te worden om alle TV ontvangers die via die lijn zijn aangesloten te bereiken. Bij unicasts, zoals bij uitgesteld kijken of kijken via NLZiet.nl, Netflix en ook de iTV app van KPN moet voor elk aangesloten apparaat een aparte stream verzonden worden.

Stel je woont in een dorp met 1000 huizen en iedereen kijkt naar het NOS journaal op NPO 1 in HD-"Glas" kwaliteit.

M.b.v. van IGMP multicasting wordt er 12,5Mbps aan bandbreedte gebruikt op de glasvezel naar jouw dorp. Als er geen gebruik gemaakt zou worden van IGMP multicasting dan zou over die glasvezel dus 12,5Gbps verzonden moeten worden.

En ja, IGMP multicasting betekent ook IGMP snooping om er voor te zorgen dat die TV streams alleen naar jouw TV ontvanger verstuurd worden en niet naar alle apparaten op jouw thuisnetwerk.

Dit is overigens bij T-Mobile precies hetzelfde.

Heb je die STB-NMC-400 meldingen ook als je (ter test) alle andere apparatuur even loskoppelt van de router, ook de apparatuur die via wifi aangesloten is?

Als je dan geen meldingen meer krijgt, sluit dan één voor één en met tussenpozen van een minuutje of 5 weer apparaten aan totdat de melding weer verschijnt. 

Zap tussendoor ook telkens even naar een andere zender.

Ik ben benieuwd bij welk apparaat die meldingen weer terug komen.

Als je overigens 100% verlost wilt zijn van die melding dan zal je de TV ontvangers op een apart vlan moeten plaatsen zolang KPN de fout niet gevonden en weggenomen heeft.

Het probleem lijkt overigens te zitten in het foutief afhandelen van andere multicasts die op de TV ontvanger aankomen. Denk hier bijvoorbeeld aan apparaten die zich m.b.v. bonjour (mDNS) kenbaar maken op het netwerk. Zo zijn er situaties bekend dat de TV ontvangers vlekkeloos werken totdat er een HP printer aan gezet wordt die zich vervolgens m.b.v. bonjour op het netwerk zichtbaar maakt.

Bij de instructies van T-Mobile, staat IGMP snooping uit.  Ik heb geen moeite met een multicast binnen mijn eigen netwerk.

Ik heb wel een idee over de veroorzaker, een tweede TV KPN kastje staat achter ouwe switches. Maar ik heb geen issues bij het streamen van de cloud platform (opname, pause/play of terugkijken). Kennelijk loopt de dataverkeer anders op die manier.

Ik weet niet zeker als ik verder ga met KPN. Ik heb ook gezeur bij het updaten van de TV kastjes, dan moet ik ze weer rechtstreeks aansluiten op de KPN modem. KPN is ook prijzig. Als ik doorga, koop ik een chromecast en misschien vervang ik de switches met ubiquity. Misschien leg ik een dedicated ethernet kabel van de modem naar TV.  
 

Dan stammen die instructies nog uit de tijd dat T-Mobile bridged-IPTV gebruikte.

Jaren terug is KPN overgestapt van bridged-IPTV naar routed-iPTV en sindsdien speelt IGMP snooping een rol. T-Mobile doorloopt momenteel dezelfde transitie van bridged-IPTV naar routed-IPTV.

Dat is niet de oorzaak van die STB-NMC-400 meldingen. Het is prima mogelijk om een TV ontvanger achter een gewone switch te hangen, het loopt dan alleen fout als je op dezelfde switch ook andere apparatuur aansluit die in standby hun netwerkkaart op 10Mbps zetten of als je er een wifi accesspoint op aansluit.

Ik zou je toch echt adviseren om het advies uit mijn vorige bericht uit te voeren.

Klopt, want dat zijn geen IGMP multicasts maar unicasts.

Dan heb je waarschijnlijk 5202's en gebruik je een andere DNS server zoals bijvoorbeeld die van Cloudflare. Klopt dat?

Ik gebruik een USG-3P samen met de switches van Unify, ik gebruik geen experia box.
Ik gebruik als basis de handleiing van Henk van Achterberg.

https://www.vanachterberg.org/usg-kpn-ftth/posts/unifi-security-gateway-kpn-ftth-iptv-ipv6/

Daarnaast heb ik eigen vlan aangemaakt voor IPTV en deze gekopppeld aan de switch poort van 5202 ontvanger. Bij mij werkt dit zonder haperingen, ik had eerst geen eigen vlan voor de ontvanger en kreeg telkens de 400 meldingen.

Precies, vandaar dat

@Marc v Z Heb jij wellicht een NAS, netwerk printer, Apple TV of Sonos in jouw netwerk staan?

Allemaal leuk en aardig maar zolang er in de Experiabox geen apart VLAN aangemaakt kan worden zitten mensen maar mooi opgescheept met deze STB-NMC-400 foutmeldingen.

Klopt, het is dan ook KPN die hier keihard aan de bak moet maar blijkbaar begrijpen ze dat nog niet helemaal bij KPN.

@wjb Ik heb 31 devices in mijn netwerk. O.a. twee keer een synology NAS, een netwerk printer, tv, Sony soundbar webcams enz.

Ik denk dat 1 of meerdere devices de storingen veroorzaken.
Ik had eerst een telfort abbo en dit heeft een lange tijd goed gewerkt gewerkt. De problemen begonnen toen KPN naar een gezamelijk TV menu ging voor alle klanten van Telfort, KPN en X4Sall.

Toen heb ik IPTV in een eigen vlan gezet en waren mijn problemen opgelost.

En toch had het niets met de overgang van Telfort naar KPN te maken, ook KPN abonnees hadden geen enkel probleem tot aan één van de laatste versies van de firmware. Die twee dingen vielen in tijd gezien zo ongeveer samen en het idee dat de overgang van Telfort naar KPN een rol.speelt berust dus puur op toeval.

Het probleem lijkt veroorzaakt te worden door ander multicast verkeer (zoals bonjour) dat niet correct afgehandeld wordt door die nieuwere firmware van de TV ontvangers. Dat is ook waarom het op een apart vlan plaatsen van de TV ontvangers een oplossing is immers de multicasts (zoals bonjour) kunnen dat vlan van de TV ontvangers niet bereiken aangezien multicast binnen hun eigen (v)lan blijven.

In jouw geval zouden de netwerk printer of de Synology NASsen best een rol hebben kunnen spelen als deze Bonjour Printer Broadcast aan hebben staan.

Ik zit ook even na te denken, weet iemand nog hoe de ‘oude tv menu’ werkte? Want het lijkt alsof de meldingen pas daarna kwamen (Q3/Q4 2020), kan het zijn dat het nieuwe tv menu nu ook middels multicast werkt, dit lijkt me logisch want je moet EN tv beeld kunnen projecteren op de tv EN een menu openklappen met in de achtergrond dus je tv beeld. Als in het vorige tv menu alleen het menu kwam zonder beeld dan zou dat mogelijk een verklaring kunnen zijn?

Het IPTV platform werkt al jaren met IGMP multicasts, ook het oude TV menu.

Dat heeft niets met IGMP multicasting te maken, IGMP multicasting betekent alleen een TV stream (het beeld) tegelijk naar meerdere TV ontvangers verstuurd wordt.

“Dan stammen die instructies nog uit de tijd dat T-Mobile bridged-IPTV gebruikte.

Jaren terug is KPN overgestapt van bridged-IPTV naar routed-iPTV en sindsdien speelt IGMP snooping een rol. T-Mobile doorloopt momenteel dezelfde transitie van bridged-IPTV naar routed-IPTV.”

De laatste verwijzingen zijn naar niet IMGP snooping. Natuurlijk kan de handleiding verouderd zijn.

Dat is niet de oorzaak van die STB-NMC-400 meldingen. Het is prima mogelijk om een TV ontvanger achter een gewone switch te hangen, het loopt dan alleen fout als je op dezelfde switch ook andere apparatuur aansluit die in standby hun netwerkkaart op 10Mbps zetten of als je er een wifi accesspoint op aansluit.

Ik zou je toch echt adviseren om het advies uit mijn vorige bericht uit te voeren.

Ga ik doen, kost geen geld! ;)

Dan heb je waarschijnlijk 5202's en gebruik je een andere DNS server zoals bijvoorbeeld die van Cloudflare. Klopt dat?

Ik weet niet wat een 5202 is en ik gebruik geen afwijkende DNS servers. Ik heb dat probleem al jaren. Vroeger had ik alleen een semi managed netgear switch (met vlan ondersteuning) en nu heb ik voor een groot deel een ubiquity omgeving (twee switches, ergens achter aan. (helaas heb ik beperkte mogelijkheid om kabels te trekken)
Ik was tijdelijk overgestapt naar de 4K decoders, echter helpt dit voor geen meter. 

Maar, ik zal zoeken naar de oorzaak en ik zal overstappen naar een dedicated vlan voor TV kastjes. 

De problemen met het haperend en stilstaand IPTV beeld bestaan als sinds vorig jaar (binnen het telfort netwerk) en is begonnen rond de tijd met het aanpassen van het TV menu.
Er zullen verschillende redenen zijn waardoor deze problemen zijn onstaan. maar ik heb een tijd gehad dat ik alleen tv kon kijken door eerst even het kanaal te pauzeren en dan weer op play te drukken.
Dit wisselde ook per week, de ene week had ik geen problemen en andere weken was het drama.

Ik heb toen ook op het punt gestaan gestaan om over te stappen naar een andere aanbieder, maar je hebt nogal weinig keuze om over te stappen naar een andere aanbieder.

Nog even inhakend op het igmp protocol, ik heb even een tijdje Wireshark laten draaien en ik zie het volgende:

Mijn TV ontvangers zitten in de range 192.168.2.68 / .69 / .70 / .71 en stonden aan op het moment dat Wireshark draaide, waarom rapporteren die niet als de Experiabox een Membership Query doet in welke Report Group ze zitten? Dan hoort ie dit toch gewoon aan te geven zoals dit bij de overige apparaten ook gebeurd (.15 is mijn desktop computer / .55 is mijn nvidia shield).

Nu zie ik oa. communicatie tussen 192.168.2.68 (ontvanger 1) en 239.255.255.250, als ik de membership reports goed bekijk dan communiceert mijn .15 en .54 en .55 ook met ditzelfde dest. address, waardoor ik me goed kan voorstellen dat de TV ontvanger hiervan in de war raakt ?

239.255.255.250 is gewoon het IPv4 mulitcast adres voor SSDP (Simple Service Discovery Protocol). Dat meerdere apparaten daarmee communiceren is volstrekt normaal.

Dat snap ik, maar meer mijn eerste vraag. Als de Experiabox een Query doet, dan moeten alle 4 de tv ontvangers (als ze aanstaan en live tv aan hebben) toch rapporteren dat ze meedoen in een bepaalde hostgroep binnen het 224.0..0/4 subnet (dus ik noem maar wat 225.100.1.50 als hostgroep)? Althans dat zou ik verwachten, en dat doen ze nu dus niet….

het is een wat oud topic maar ik heb eenzelfde probleem met de TV-ontvanger op de slaapkamer.

Ik weet niet precies wanneer deze problemen is gaan geven maar ik krijg em eigenlijk niet meer goed werkend. Ik gaf het eerst op de onder de de nieuwe badkamervloer gestorte UTP-kabels, heb een nieuwe Cat6 getrokken van de Experiabox naar de Gigabit-Switch achter de WK-TV.

De TVbox achter de TV doet het goed, plaats ik die SLK-box even aan de stroom/utp van die achter de TV beneden staat dan update/start ie goed.

De bekabeling naar de SLK loopt naar beneden, inmiddels via een nieuw getrokken Cat6 naar een Asus RT-AX88U en die loopt weer naar die Switch achter de WK-TV.

Heb vandaag de kabel+switch die op kantoor staat al even losgekoppeld maar dat maakt verder niet uit.

De TV kan even (buffer?) beeld hebben, daarna stagneert het met de melding stb-nmc-400 om na xx seconden weer even beeld en geluid te geven.

Ik heb hier best veel apparaten in  het netwerk hangen zoals Hue, Alexa en alles wat maar op Wifi/netwerk aangesloten kan worden, De verbinding is 200Mbit KPN glas. Heb verder eigenlijk nergens anders klachten, Wifi-speedtest.net is bijna 200mbit down en 200-300mbit up

Begrijp ik het goed dat de lijn van die TV ontvanger naar "Internet" via die Asus loopt?

Heb je het probleem ook als je die Asus daar even tussenuit haalt?

de probleem-ontvanger ja, ik zal even zoeken of ik nog een losse switch heb liggen op de zaak, de UTP is niet lang genoeg om vanuit de standplaats van die Asus naar de Switch achter de TV te komen.

Nu is het zo dat die Asus er al een tijdje staat, niet dat die nieuw is en sindsdien slecht doet.
Nu kan een firmware-update natuurlijk roet in het eten gooien maar ik akn dat niet achterhalen omdat we te weinig boven kijken.

Zorg dan wel voor een switch die IGMP snooping ondersteunt.

Dan kan ik sowiezo beter kijken of die Switch achter de TV vervangen moet worden, aangezien er daar natuurlijk ook 1 box achter hangt(als stond die uit ten tijde van de update-poging vandaag)