NLZiet geeft uitleg over technische problemen tijdens Champions League-finale

NLZiet had zaterdag 1 juni last van technische problemen tijdens de finale van de UEFA Champions League. Kijkers misten daardoor de tweede helft van de wedstrijd tussen Borussia Dortmund en Real Madrid. De streamingdienst geeft nu uitleg over hoe dit kon gebeuren.

Volgens NLZiet ging er rond 22.00 uur, net voor aanvang van de tweede helft van de wedstrijd, iets mis met het omzetten van de uitgezonden beelden naar een stream. De streamingdienst zegt nog niet precies te weten wat er misging en onderzoekt de oorzaak momenteel met de leverancier van de beelden. Door de problemen liep de speler in de app vast. Doordat veel kijkers gelijktijdig de app opnieuw probeerden te starten, raakten de servers vervolgens overbelast. De problemen werden hierdoor volgens NLZiet verergerd.

Om herhaling te voorkomen gaat NLZiet in gesprek met de leverancier en wil de streamingdienst ervoor zorgen dat een stream niet meer weg kan vallen, onder meer door alternatieve back-upoplossingen te vinden. Tijdens piekmomenten, zoals het EK voetbal, gaat NLZiet er daarnaast voor zorgen dat er een 'overdreven hoeveelheid extra servers' actief zijn tijdens wedstrijden.

Reacties (74)

[Luchtbakker]

Ik ben niet helemaal thuis in de broadcast wereld. Maar op private netwerken maak je gebruik van multicast om het dataverkeer vanaf de bron te beperken, op het moment dat bijvoorbeeld 100 man naar de zelfde stream wilt kijken.

Is dat met live tv niet het zelfde? Een media router die gewoon de authenticatie sleutel (decryptie sleutel) geeft zodat jij de stream kan decoden?

Waar heb je dan een hele berg aan servers voor nodig?

[Reactie gewijzigd door Luchtbakker op 22 juli 2024 13:26]

[Barryke]

Goede vraag. Dat kan inderdaad niet.

Multicast op internet met HTTP bestaat niet, omdat het niet kan. HTTP gebruikt namelijk TCP voor de data pakketjes, en hiermee is geen one-to-many verkeer mogelijk.
https://networkengineerin...multicast-possible-in-tcp

NB. En daarbij zou HTTPS nog steeds veel rekenkracht vereisen per client, en dus servers.

Maar hoe werkt Multicast dan WEL ?
Multicast op lokale netwerken werkt met UDP, dit kan je zien als de “geen-ontvangst-bevestiging” versie van TCP. Met UDP is het mogelijk om op een best-effort en onbetrouwbare manier meerdere IPs of hele subnets te voorzien van dezelfde data. (Zoals inderdaad een live video stream, of multiplayer game)

Nu kan je denken dat zou dus op internet ook wel handig zijn, een UDP Multicast, maar dat hebben ze bewust niet toegestaan. Het zou alles overbelasten en platleggen (m.a.w. een DDOS) te makkelijk maken.
https://networkengineerin...t-possible-and-if-yes-how

Ik ben niet helemaal thuis in de netwerk wereld, maar zo begrijp ik het. Verbeteren welkom!

[Reactie gewijzigd door Barryke op 22 juli 2024 13:26]

[Nollekeuh]

Dat komt omdat de data over internet gerouteerd verzorgd wordt en daarmee multicasten over hele subnets vervalt. Er zit NAT tussen met encapsulatie waardoor het casten niet door komt. De techniek is totaal niet geschikt om over je NAT heen te gaan. Mocht dat wel lukken door te forwarden, kom je bij de volgende hub weer een obstakel tegen met een nieuw subnet waarin je oorspronkelijke cast niet mee genomen was en er meestal firewall regels zijn die dit verkeer niet toestaan. Je hebt zeg maar routeerregels nodig om dit verkeer netwerktechnisch door te zetten. Standaard staat dit allemaal uit, omdat er anders heel veel nutteloos verkeer doorgezet wordt. We willen op internet namelijk alleen maar nuttig verkeer om het zo efficient mogelijk te gebruiken en zeker tijdskritisch verkeer (telefonie en videobellen of websites bezoeken) voorrang te geven. Laat je castingverkeer toe, slibt de router dicht. Dus ja, je kan casten, maar dat blijft beperkt tot interne netwerken. We gebruiken OSI L2 en L3 technieken niet voor het doorzetten van streams over internet, dat gebeurd op laag 4 en hoger.

Ik heb multicast op interne netwerken alleen maar zien werken na allerlei toevoegingen op de routerende switch tussen vlans of op subnets, bijvoorbeeld voor intercom systemen.

[Reactie gewijzigd door Nollekeuh op 22 juli 2024 13:26]

[MarcoC]

KPN TV gaat over multicast, wel een apart VLAN.

[TechSupreme]

Als je intern een IP scanner erop los laat zal je zien dat het KPN kastje gewoon een intern IP adres krijgt van je modem op hetzelfde subnet en VLAN. Het verkeer wordt bij het modem afgeleverd over een aparte VLAN en via IGMP snooping wordt het verder verdeeld naar de kastjes.

Een eigen modem bij KPN is daardoor praktisch onmogelijk tenzij je diep in de techniek duikt en flink investeert in hardware. Een managed switch tussen je modem en het kastje is al genoeg om het te verstoren. Daarom moet je het TV-kastje ook direct op je modem aansluiten.

[Reactie gewijzigd door TechSupreme op 22 juli 2024 13:26]

[johnbetonschaar]

Ik gebruik KPN iPTV met een eigen router (UniFi USG), met wat extra configuratie is dat is prima te doen.

Het IPTV verkeer komt op een VLAN binnen als multicast (dus niet op de IP voor de rest van het verkeer), en wordt dan naar je LAN gerouteerd door een IGMP proxy die je zelf moet configureren.

Ik had het zelf nooit uit kunnen vinden hoe je dit werkend krijgt maar er is genoeg over te vinden inclusief GitHub repos met scripts die de juiste configuratie uitvoeren.

[TechSupreme]

Ja ik heb ook een USG (is tevens de enige die IGMP Snooping ondersteunt want alles wat daarna komt kan het niet meer). De kosten en de kennis ging het om. Je moet diep in de USG duiken en dingen handmatig configureren om het werkend te krijgen en houden.

Zover ik weet is er maar 1 repo en een website die door dezelfde persoon worden onderhouden. Toen ik het jaren geleden deed had je alleen de website van Henk van Achterberg en de repo van Bas Meerman, beide geen script. Misschien dat ze dat ondertussen wel hebben toegevoegd.

[Reactie gewijzigd door TechSupreme op 22 juli 2024 13:26]

[johnbetonschaar]

Als je alles zelf moet uitzoeken is het inderdaad niet te doen, maar gelukkig hebben andere mensen dat al gedaan, en dan valt het reuze mee, ik heb er al drie jaar geen omkijken naar, en als ik het nu opnieuw zou willen configureren is het alleen maar de correcte gateway config JSON provisionen en een hook scriptje op de USG neerzetten om de route table te monitoren en zo nodig verversen. Niet zo makkelijk als gewoon de router van KPN gebruiken inderdaad maar voor een beetje tweaker prima te doen ;-)

Overigens is 'IGMP snooping' slechts een functie in de router & switches om te zorgen dat het multicast verkeer niet onnodig naar alles en iedereen op je LAN wordt doorgestuurd, in theorie werkt IPTV zelfs met switches die geen IGMP snooping ondersteunen alleen is de kans dan groot dat je netwerk overspoeld wordt met IGMP verkeer en alles zo traag wordt dat het beeld gaat haperen en wegvallen. De IGMP proxy is het specieke extra dingetje dat je nodig hebt op de USG, wat die doet is simpelweg het IGMP verkeer van het multicast IP netwerk naar je LAN routen.

[TechSupreme]

Wat als ik niet in de 192.168 range zit en een grotere subnet heb?

[MOmax]

Nou, eigen modem bij KPN en diverse managed switches tussen Fritzbox en KPN STB. Het heeft allemaal gewerkt hier, dus er staan een paar onwaarheden in jouw tekst.

[TechSupreme]

Zeg ik ergens dat het niet werkt? Ik zeg alleen dat een managed switch genoeg is om het niet te laten werken, dat wil zeggen dat je alles goed geconfigureerd moet hebben.

[Mikemkm]

TV hoeft niet direct op je modem
Als je een switch gebruikt die IGMP snooping ondersteunt werkt het prima (KPN bied deze zelf ook aan in de shop => Netgear GS105E)
Gebruik dit in huis op meerdere plekken
Nooit problemen. Elke TV hangt achter een switch.

Netgear GS105E
Met de switch kun je het aantal Ethernetpoorten op je modem met 4 uitbreiden. Interactieve tv-ontvangers, Wifi versterkers, computers en andere netwerkapparatuur kunnen op de switch worden aangesloten.

De switch is meteen te gebruiken en heeft ook geavanceerde functies waar je gebruik van kunt maken. De Netgear GS105E switch biedt onder andere de mogelijkheid tot:
Het opzetten van meerdere virtuele netwerken (VLAN’s)
Instellen van mirror poort waardoor bij complexe problemen traces gemaakt kunnen worden
Snelheidsbeperking per poort

Specificaties:
5 x 10/100/1000 Mbps auto-sensing RJ-45 poorten
Full en half duplex
IGMP snooping
Webinterface voor eenvoudige configuratie

[Reactie gewijzigd door Mikemkm op 22 juli 2024 13:26]

[TechSupreme]

Ik zeg ook niet dat het direct op de modem moet, ik zeg alleen dat KPN dat aanraadt. Is het eerste wat de helpdesk zegt als je TV niet goed werkt.

[Ricco02]

Het ene TV Kastje wel. Andere TV kastjes van KPN gebruiken weer Unicast.

Ligt er maar net aan welke je hebt.

[MarcoC]

Ze gebruiken allemaal multicast, maar bij de nieuwste TV+ ontvanger (DIW7022) krijg je de mogelijkheid om unicast ipv multicast in te stellen.

[Nollekeuh]

Dat is dus het interne netwerk van KPN waarop het gecast wordt.

[RefriedNoodle]

Ik heb multicast op interne netwerken alleen maar zien werken na allerlei toevoegingen op de routerende switch tussen vlans of op subnets, bijvoorbeeld voor intercom systemen.

Die keren dat ik met multicast gewerkt heb, was het juist voor meerdere videostreams van satellietontvangers naar tv's op hotelkamers. Elke zender had z'n eigen multicast-adres.

En omdat dat er een stuk of 20 waren, trokken we daarmee de switches onderuit want die gingen permanent alle streams doorgeven op alle poorten. Daar leer je heel snel wat IGMP snooping voor dient (namelijk: alleen multicast-verkeer op een switchpoort doorgeven als de host er ook om vraagt).

[GertMenkel]

Multicast in de browser kan wel, echter niet over HTTP. WebRTC kan bijvoorbeeld multicast doen. Ik geloof dat kickstarter een tijdje een livestreamingplatform had dat daar gebruik van maakte, de latency was minimaal, maar de kwaliteit en CPU impact was wel hoog. Bij apps buiten de browser kun je wel gewoon UDP gebruiken natuurlijk.

Er zitten nog wel wat nadelen aan multicast (NAT maakt het erg lastig voor de mensen die nog achter IPv4 vastzitten, om maar iets te noemen) maar de browser-API's zijn niet wat multicast hier onmogelijk maakt.

[vrow]

I want to tell you a joke about UDP, but I’m afraid you might not get it :-)

[nl_amun]

Volgens mij word om dit probleem heen gewerkt door een websocket te gebruiken.

Wikipedia: WebSocket

Correct me if i'm wrong

[Oon]

Je krijgt een unieke key bij het laden van de stream, die key hoort bij je account en je huidige sessie. Als je opnieuw inlogt of je browser/app herstart, of zelfs de stream helemaal sluit en weer opent, krijg je een nieuwe key.
Dit is gewoon DRM, maar betekent dus ook dat ze weinig verkeer kunnen delen, want iedere stream is versleuteld met die unieke en tijdelijke key.

[ThaGuus]

Dit is niet het geval. NLZiet en bijna alle streamingdiensten versleutelen hun streams met dezelfde sleutel voor elke gebruiker. Deze sleutel wordt vaak gerouleerd (en verschilt natuurlijk per kanaal/video en vaak ook per resolutie), maar blijft voor elke gebruiker hetzelfde. Wat je waarschijnlijk hebt gezien in je browser, is de PlayReady/Widevine request en response. Dit is niet de uiteindelijke sleutel, maar eerder een soort handshake waarmee het certificaat in je browser of de TEE-chip op je telefoon de uiteindelijke sleutel kan verkrijgen.

[Mavamaarten]

Zo werkt het ongeveer, maar ook niet helemaal. Je hebt een bronstream, die wordt getranscode en in segmenten van een 2 tot 10 seconden geknipt en gepackaged tot een DASH of HLS stream. Encryptie is ook een proces daarbovenop. Het is inderdaad zo dat de license om te decrypten los van de content segmenten wordt gedistribueerd via een license server.

Alle aparte segmenten komen terecht in een S3 bucket of iets dergelijks. Je clients halen die uiteraard niet rechtstreeks uit die Origin bucket op (dat zou qua kosten niet te doen zijn), maar worden gecached door een CDN als Akamai of CloudFront. Zo'n cdn is exact de dienst die de load op je eigen systemen laag houdt en speciaal voor zo'n hoge load scenario's bestemd is.

Storingen kunnen op allerlei plaatsen voorvallen. Bij de origin/bronstream, bij het transcoden, bij het packagen, bij de CDN die te vaak naar Origin moet gaan (cache misses) maar ook monetizatie is een belangrijk aspect waar het een ander kan mislopen.

[brambo123]

NLZiet is niet onderdeel van je internet pakket zoals dat bij KPN bijvoorbeeld is.
Hierdoor kunnen zij geen multicast gebruiken zoals KPN dat doet.

Overigens heeft KPN vroeger ook gehad dat storingen verergert werden doordat gebruikers decoders gingen herstarten.
Het multicast netwerk kan dan weer werken, maar alle decoders die herstarten proberen software op te halen kunnen de servers vervolgens niet aan.

[Qauters]

Dat werkt exact zo met je iptv box van bijvoorbeeld KPN (multicast over een aparte vlan).

NLZiet is echter een gewone internet streaming dienst en die kunnen geen gebruik van van multicast, net zoals Netflix etc.

[TechSupreme]

Multicast over internet is om technische en praktische redenen niet mogelijk.

Multicast werkt in de praktijk heel simpel. Pakketje komt binnen op een poort -> kopieer dat naar alle andere poorten. Dit is een hele makkelijke manier om heel het verkeer vast te laten lopen, daarom wordt het ook standaard geblokkeerd.

Multicast verkeer kan daarom alleen over interne netwerken en het werkt alleen op netwerken die goed geconfigureerd zijn.

Om ervoor te zorgen dat intern alles niet vastloopt, is het een goed idee om het te onder te brengen in een aparte VLAN zodat het verkeer alleen gaat naar poorten die het nodig hebben.

Multicast over internet loopt over een VPN of andere vorm van een bridge.

[Skix_Aces]

Multicast werkt in de praktijk heel simpel. Pakketje komt binnen op een poort -> kopieer dat naar alle andere poorten. Dit is een hele makkelijke manier om heel het verkeer vast te laten lopen, daarom wordt het ook standaard geblokkeerd.

Wat je hier beschrijft is broadcast. Dit is een "domme" manier om een bericht op alle aangesloten devices te krijgen. Het ARP protocol werkt bijvoorbeeld zo om het MAC adres achter een IP address te achterhalen.

Multicast werkt (normaal gesproken) iets slimmer. Een multicast source stuurt multicast pakketten naar de switch met een specifiek multicast adres (anders dan het IP adres van dat device). Apparaten die in deze multicast stream geïnteresseerd zijn kunnen een join verzoek sturen op het multicast adres van de source die ze willen ontvangen. De switch zal dan, indien correct geconfigureerd, de multicast pakketten naar de geïnteresseerde devices doorsturen.

En daar gaat het vaak mis. De switch moet hiervoor IGMP snooping aan hebben staan, omdat multicast informatie op een andere laag van de IP stack zit waardoor hij de pakketten moet parsen om te weten wat hij moet doen. Als de switch dit niet ondersteund of als het uit staat kan hij er voor kiezen om alle pakketten de droppen, of om het als een broadcast uit te sturen. Beide situaties zijn uiteraard ongewenst.

[Froos]

Ik heb er net zo min verstand van, maar ik kan me goed voorstellen dat er een digitaal video signaal wordt aangeleverd dat moet worden gecodeerd naar een stream en vervolgens, na authenticatie, naar client wordt verstuurd. Lijkt mij dat je daarvoor wel voldoende connection brokers nodig hebt, servers die de clients aan de juiste datastream knopen. En er zijn natuurlijk ook nog mensen die geen EK kijken. Die moeten ook bediend worden.

Wij hebben nu zo’n 4 jaar uitsluitend NLZiet als TV aanbieder en tot nu toe hebben we nog geen uitval gehad 🤞🏻 Wij hebben dus geen klachten. Maar, goed dat ze voorbereid zijn.

[Nedje]

Maar ze waren dus niet voorbereid, dat gaan ze, naar aanleiding van dit incident op orde brengen.

[Reactie gewijzigd door Nedje op 22 juli 2024 13:26]

[pe0mot]

Welke stagiaire of AI heeft deze kul geschreven:
1 " NLZiet geeft uitleg over technische problemen "
2 " De streamingdienst zegt nog niet precies te weten wat er misging en onderzoekt de oorzaak momenteel met de leverancier van de beelden."

[Naafkap]

Niet alleen bij NLZIET waren er problemen, ook leek er bij RTL zelf af en toe wat storing te zijn. Het logo bleef wel in beeld, maar de wedstrijd viel eventjes weg voor een paar keer.

[Wheres My Money]

Dat is wel eens vaker bij live (voetbal) wedstrijden. Dat ligt aan de leverancier van de beelden, in dit geval Sky Sports. Wat NLZiet overkwam vind ik ook echt niet kunnen

[William_H]

Jij vindt het niet kunnen, wat als klant logisch is, maar ik denk dat ze het bij NLZiet ook best hoofdpijn heeft bezorgd.

On topic. Dit soort issues los je niet eventjes op tijdens een wedstrijd. Dit is configuratiewerk. Iets wat overdag, als iedereen aanwezig is, misschien nog opgelost had kunnen worden, maar dan nog, zoiets los je vaak niet even in 3 kwartier of minder op.
Het is geen aflevering van CSI.

[William_H]

Het kan best zijn dat dat een domino effect heeft gecreëerd. Misschien heeft die storing net even te lang geduurd, stream verloren, en één of ander vreemd proces is ontstaan.

[Marve79]

Lijkt wel op illegale iptv, daar valt de stream ook altijd stil op het meest vreselijke moment

[Bongoarnhem]

Illegale iptv werkt veelal beter dan mn NLZiet abonnement🙈🙈🙈

[Username3457829]

Hetzelfde op Ziggosport. Ik heb niet gekeken wat er op Veronica gebeurde, omdat het te kort van duur was.

[mr_MKZ]

Dit was een onsite probleem weet ik uit een bron Dus iedereen had hier last van.

[Reactie gewijzigd door mr_MKZ op 22 juli 2024 13:26]

[Stijnvi]

Dit was op Ziggo ook. En gezien het logo wel in beeld bleef duidt dit op een probleem vanuit de bron van het signaal en niet bij de zender.
Bij NLZiet viel de hele zender uit als ik het goed begrijp.

[Joncik91]

Op de Belgische TV (VTM) waren er ook heel kort problemen, met een melding, emergency broadcast met witte achtergrond, oid. Was niet langer dan een minuut (of twee)

[Nedje]

Goh, luchtalarm nog even af laten gaan en je hebt wel een recept voor een leuke actiefilm. Oh wacht, die is er al.. Evengoed wel zuur, het zijn niet echt gebeurtenissen die je zomaar eventjes nogmaals kunt doen.

[mwa]

Dat was inderdaad erg irritant! Ik had gelukkig nog een login van een familielid voor de KPN app (en ziggo), dus kon snel schakelen.

[HollowGamer]

Dat is echt de IT-oplossing als je het probleem niet weet: 'we gooien er meer servers tegenaan', 'meer memory' of 'upgraden naar de volgende tier'.

Het probleem zal wel in het midden zitten. Te weinig resources, maar ook ergens een memory lek/loop.

Weet iemand hoe ze dit doorgaans aanleveren?
Moet ik denken aan een HLS/DASH stream of echt een directe uplink via de schotel?
Het klinkt namelijk als het eerste.

[William_H]

Klinkt ook lekker als woordvoerder-praat. Zo van, dan nemen mensen ons serieus. Terwijl, als het een verloren stream is, misschien er iets misging met een authenticatie of het opnieuw oppikken van een stream of inderdaad een ander soort loop. Dat de hele stream down ging zal geen toeval zijn.

[ShakerNL]

Ik keek online via de gratis Ziggo Sport Free zender die voor iedere Nederlander zonder kosten beschikbaar is. Daar had ik geen last van de stream. Wel zag ik af en toe ruis op één van de camera's, maar dat leek mij meer een probleem bij de tribune.

[De_Daapse]

Gelukkig weten we nu waarom we de wedstrijd gemist hebben

[hk9999_33]

Om herhaling te voorkomen tijdens de sportzomer toch maar mijn abo elders ondergebracht. Overigens een mail van NLZiet ontvangen met uitleg, echter zonder enige vorm van excuses (laat staan compensatie). Dat was voor mij de spreekwoordelijke druppel.

[kernie]

Het ontbreken van excuses viel mij ook op, dit zou ik persoonlijk op een hele andere manier communiceren...

[Kimbo72]

Ik ben helemaal klaar met NL ziet.
Een app die steeds programma's laat zien om verder te kijken die ik niet wil kijken haal je deze weg komen ze toch weer terug.
Een menu waarbij je flink wat terug moet klikken om weer terug in het hoofdmenu te komen.
Weer een euro extra betalen en dan nu weer dit.

[mcmd]

Er zijn best wel onhandige dingetjes in de app, maar toch ben ik zelf tevreden met NLziet. Ik blijf voorlopig nog klant bij ze.
Wat de storing betreft, wist nog geeneens dat er voetbal was, ook niet gemist :-)