Hier in huis aanhoudende problemen met TV en radio. Met regelmaat (eens in de 10 - 30min) valt het signaal weg. Vaak komt het weer terug, soms moet je overschakelen. Het is irritant tot onbruikbaar. Al het internetverkeer verloopt wel vlekkeloos. Altijd, alles. Ook Netflix en grote meetings in MS Teams.
Ik heb al vrij veel geprobeerd. Heeft iemand nog een goede suggestie?
Router
Fritzbox 7590
uitgewisseld met een ouder model Fritzbox 7490, maakt geen verschil
kabel naar Amino op andere poort, geen effect
de poort ingesteld op 1 Gb/s of op 100 Mb/s, maakt geen verschil
prioriteit ingesteld op de Fritz, voor die poort, geen verschil
alle andere apparatuur (tijdelijk) afgekoppeld, maakt geen verschil
Kabel naar Amino
uitgewisseld voor ander exemplaar, geen verschil
Herstarten
Uiteraard alles herhaaldelijk opnieuw ingeschakeld.
Netwerkkwaliteit
Bekabeld gemeten:
Speedtest
Beter dan 900 Mbit up en down
Ping: 4,5 ms jitter 1ms
Dat lijkt me prima, toch?
MacOS networkQuality
Responsiveness: High, 39 ms, 1527 RPM
Uplink: 253 Mbps
Downlink: 840 Mbps
(dit is een andere manier van meten)
Deze waardes zouden toch voldoende moeten zijn?
Ik kan nog een paar zaken bedenken:
de amino heeft een fout
→ hoe kom ik aan een andere amino om te testen?
er treedt vertraging op in het netwerk, te lang voor de amino om te bufferen. Maar opvallend is dat radio met minder data er ook last van heeft.
→ Is er een manier om die datastroom te monitoren?
→ heeft iemand een idee wat de eisen zijn aan de datastroom, welke variatie in datapakketjes overleeft een amino?
→ is er een handige app in linux of macOS om gedurende langere tijd een datastroom te monitoren en variatie (jitter) in netwerkverkeer te meten?
→ is het ip adres van de datastroom naar de amino bekend? Is die stroom zelf te meten?
Ik heb enigszins de aanschaf van het allernieuwste model Fritz in gedachten, als die op de markt beschikbaar komt vanaf augustus. Daar kun je rechtstreeks de fiber inprikken. Maar het is wel een forse uitgave.
Ik verwacht geen instant oplossing, meedenken wordt zeer gewaardeerd.
Dit is een bekend verschijnsel dat erop wijst dat de UDP verbinding vanaf de Canal+ servers tot aah je router ergens hapert. Freedom kan dit (laten) oplossen. Bij mij heeft het ongeveer anderhalf jaar geduurd voordat de live TV verbinding over UDP ongeveer feilloos werkte.
Het lijkt erop dat alleen live TV kijken via de Amino die verbinding gebruikt. Andere methoden (app, website, Chromecast, etc.) gebruiken allemaal TCP. TCP verbindingen naar alle ontvangers kosten meer dataverkeer dan UDP en daarom wil een provider natuurlijk UDP gebruiken. Maar het blijkt lastig om goed te krijgen.
De grootste boosdoeners voor haperende televisie zijn toch zaken in het eigen netwerk achter de FRITZ!Box:
Switches die geen IGMP ondersteunen (of dat niet correct doen). In veel gevallen zijn het vooral TP-Link switches (SG10x serie, dus 5 poorts, 8 poorts of 16 poorts) die voor problemen zorgen.
ONT’s, NTU’s, routers etc. die eens een herstart nodig hebben. Zorg er voor dat je al de apparatuur herstart (of in ieder geval voor 20 seconden van het stroom haalt)
Niet correct ingestelde eigen hardware (dat kunnen meerdere instellingen zijn en is vaak lastig door ons te achterhalen wat er dan mis zou zijn)
Loops in het netwerk. Denk dan aan bijvoorbeeld een wifi repeater die zowel via LAN als WLAN met de FRITZ!Box verbonden is. Dan gaan apparaten tegen elkaar praten.
STB aangesloten op gastennetwerk poort of op blauwe WAN poort. Het beste kun je bij een FB7590 LAN 2 of 3 gebruiken voor de STB.
FB niet up-to-date.
In sommige gevallen willen camera systemen en video deurbellen ook nog wel eens problemen veroorzaken, vanwege het feit dat deze (in sommige gevallen) ook multicast gebruiken voor het verzenden van de video streams.
Natuurlijk kunnen er ook dingen in het netwerk van de belichter zorgen voor issues, maar daarvoor moeten we eerst op klantlocatie zaken uitsluiten.
Dat was bij ons het geval. Wij kregen met niets anders dan de Amino via de door Freedom geleverde kabel op de van Freedom gehuurde Fritzbox (7590) en al de rest uitgeschakeld geen betrouwbaar TV signaal door. Dat lag aan de belichter.
Nu met alles in bedrijf, dus ook een (Eufy) deurbel en bewakingscameras, twee Fritz wifi mesh repeaters, laptops telefoons, macbooks, een kleine server, en de Amino kabel in een Fritz wifi repeater dus niet met kabel rechtstreeks vanaf de Fritzbox… nog steeds geen enkel probleem met het UDP signaal om live TV te kijken. Maar dat heeft dus anderhalf jaar uitzoeken gekost, want als klant word je niet gemakkelijk geloofd als je vermoed dat het probleem toch echt in de verbinding tussen de Canal Digitaal servers en je Fritzbox thuis zit (of in het Amino kastje, maar dat is met de huidige software al lang opgelost). In dat netwerk zitten blijkbaar nog knooppunten die IGMP niet goed doorgeven waardoor je UDP stream wegvalt.
Ja natuurlijk ligt het aan de klantzijde. Bij TV van KPN (XS4ALL) was dat in precies hetzelfde netwerk nooit een probleem.
Ik hoefde mijn Fritz!Box nooit te herstarten voor TV van KPN (XS4ALL)
Het systeem van Canal+ is gewoon niet robuust en veroorzaakt problemen in de Fritz!Box.
Als het probleem steeds bij de klant wordt neergelegd en een reset als goede oplossing wordt gezien, dan wordt de echte oorzaak nooit opgelost. Het is technisch gezien compleet de verkeerde houding.
IP-multicast is helaas een slecht begrepen netwerktechniek. Er is een hoop onkunde bij operators en bij fabrikanten.
Toch maakt het ons als ISP qua bandbreedte niet veel meer uit hoor. Niet dat het helemaal geen punt van zorg is maar veel mensen kijken ‘on demand’ en dat is allemaal TCP. Die bandbreedte moeten we dus toch wel leveren.
Mij persoonlijke bezwaar tegen TV-over-TCP t.o.v. TV-over-UDP/IP-multicast zit niet in het netwerk maar zit bij de bron. Het zit daar waar de TV-streams worden gegenereerd. Voor multicast is dat er in principe maar één server… Ja één, en dat hoeft niet eens een dikke stroomvreter te zijn.
Hoe anders bij TCP-streams. Daar moet er er voor elk scherm een aparte stream worden gemaakt. Het aantal TCP-sessies per server is beperkt, daarom heb je hebt er al snel meer van nodig.
Als er zeg 3 miljoen schermen allemaal de dezelfde voetbalwedstrijd tonen dan zijn dat ook 3 miljoen TCP-sessies. Met zeg 50k sessies per server heb je dus 60 dikke servers om precies dezelfde data 3 miljoen keer te versturen. Dus ook tenminste 60 keer het energie gebruik. En dat eigenlijk alleen vanwege onkunde waar het multicast betreft.
Maar ja… die servers zijn er wel bij CDNs (content delivery networks), zoals Akamai en Fastly en Limelight en uiteraard bij de grote drie superscalers (Amazon. Google, Microsoft). Oh… en die zouden aan de hand van de TCP-sessies ook heel precies data omtrent kijkgedrag kunnen verzamelen.
KPN (XS4ALL) doet ook multicast - sterker, we gebruiken hun multicast-boom. Er is zijn wel een paar verschillen. Ik denk dat het meest relevante verschil zit dat in ieder geval hun Arris TV-kastje latente netwerkproblemen weet te verhullen.
Want dat kastje begint na elke zenderwissel met unicast. Pas als multicast goed doorkomt schakelt de unicast-sessie uit en en gaat het verder op multicast. Het ding doet dus gewoon unicast als multicast het niet blijkt te doen.
Helaas heeft Canal+ besloten om alleen multicast te doen met als argument dat bovengenoemde techniek de ‘zaptijd’ niet wezenlijk verkort. Wat de forse investering niet zou rechtvaardigen. Dat deze manier van werken óók multicast-problemen verhult lijkt helaas nooit te zijn meegenomen in die afweging.
Eens… en dat doen we ook niet! Zo besteed ik veel meer tijd dan ik zou willen in het overtuigen van onze lieve belichters (access-netwerken) als er écht een probleem is met de multicast-doorgifte.
Wat Bastiaan zegt is dat we de klantlocatie eerst moeten uitsluiten voordat we het bij de belichter kunnen opbrengen. Temeer omdat de problemen ook wel heel vaak toch bij de klant blijken te zitten. Daarbij helpen we de klant altijd zo goed als mogelijk. De bekende reset-riedels horen daar nu eenmaal bij.
Laten we het daarbij? Zeker niet! We blijven Canal+ pushen tot een beter product. En het is al heel veel beter dan het was.
Tevens hebben we AVM om een aantal features gevraagd waarmee we via de Fritz!box multicast beter kunnen debuggen en monitoren. De Fritz!box bevat namelijk waardevolle informatie die we er nu nog niet uit kunnen trekken.
Dan zou toch iedereen dat probleem moeten ervaren? Bij ons werkt de Amino al weer geruime tijd probleemloos (afgezien van de automatische standby na 8 uur.
Bij ons deed die dat niet. Dus heb al enige tijd afscheid genomen van de Amino’s, de app was beter. We hadden 3 amino’s, 2 teruggestuurd, één werkeloos in de kast.
Maar ook de app is slecht, pauzeren werkt eigenlijk nooit goed, terugkijken en opnemen werkt niet goed en nog meer frustraties.
We evalueren nu NLZiet. Dat lijkt hem te worden, volgende week beslissen we.
Wij hadden 2 Aminos. Hebben 1 teruggestuurd. De andere was een tijdje werkloos. We hebben toen 2 Chromecast dongels gebruikt. Dat werkt voortreffelijk, ook pauzeren en terugspoelen. Af en toe de Amino terug geprobeerd (vooral omdat de afstandsbediening beter is). Opeens ging het met die Amino weer goed, en dat doet het nu nog steeds.
Dus wij blijven nog maar een tijd bij Canal+ tot er iets beters komt. NLziet is nogal beperkt qua zenderaanbod…
Wij hadden drie Amino’s. Twee teruggestuurd, daarna overgegaan op Chromecasts. Dat werkte met de Canal+ eerst redelijk. Pauzeren bleef beperkt tot maximala een minuut of vijf.
Maar het werd steeds slechter. Dus iets wat werkt wordt steeds slechter.
Ik heb er geen enkel vertrouwen meer in.
Wow, wat veel bijdragen, dank. Ik was even op vakantie. Daar geen TV gezien :-).
De uitleg over multicast en udp geeft inzicht.
TCPDUMP UDP geeft teveel info om chocola van te maken. Wat wel opvalt, ik zou verwachten dat de UDP pakketjes met een strikte regelmaat binnen zouden stromen, maar ik zie af en toe een hele stapel pakketjes en dan weer even niks. Slag om de arm, ik weet niet of ik de uitvoer goed interpreteer.
Bastiaan’s checklist:
Ik loop de checklist even langs:
Switches die geen IGMP ondersteunen
De STB is direct op de fritzbox aangesloten, bekabeld op poort 2. Ik heb getest zonder verdere bekabelde devices in het netwerk. Maakt geen verschil. Verder is er alleen een bekabelde Netgear GS105 aanwezig. Maar daar zit dus niet de Amino achter.
ONT’s, NTU’s, routers etc. die eens een herstart nodig hebben.
Uitgebreid gedaan.
Niet correct ingestelde eigen hardware
Tsja, met alleen een Fritzbox en de automatische instelling voor Freedom, what else could be wrong?
Loops in het netwerk.
Er is hier een Fritz repeater aanwezig. Maar die is niet bekabeld aangesloten. Ook als die van het net is blijft de storing.
STB aangesloten op gastennetwerk poort of op blauwe WAN poort.
De blauwe WAN poort is voor het glasvezelmodem.
FB niet up-to-date.
Is up to date
andere multicast devices
Niet aanwezig.
Kan de fout toch hier thuis liggen? Ja, natuurlijk. Maar het zou wel fijn zijn wanneer die is te isoleren.
Als de amino is uit te lezen en aangeeft ‘missing udp packets’ dan weet ik meteen veel meer
Als ik een virtuele client kan draaien op een Mac die de UDP pakketjes bekijkt, ook goed.
Ik gooi de amino er niet graag uit omdat we ook het audio signaal via de Toslink poort gebruiken.
Misschien is het een idee wanneer Freedom een complete leenset kan aanbieden om te testen?
Freedom hoopt dat dergelijke problemen bij de gebruiker thuis zitten maar in het glasvezelnetwerk zitten nog teveel knooppunten waar de IGMP boodschappen niet correct worden verwerkt of doorgegeven. Zo zie je een stroom aan pakketjes, maar als je IGMP boodschappen niet doorkomen dan valt de UDP stroom stil, om geen stroom UDP pakketjes te blijven sturen in een richting waar geen ontvanger zit. Freedom kan dit (laten) oplossen en dat is bij ons ook gebeurd. Dat heeft anderhalf jaar geduurd…
Dat is werkt voor de radio zo maar daar weet ik nu de multicast-groepen niet van. Commerciële zenders kun je niet zien/horen vanwege de DRM.
Ik zou het wel een interessant experiment vinden om te zien of het wél met VLC werkt als het met de Amino niet lukt. Mijn vermoeden is namelijk dat de nieuwste problemen niets met multicast te maken hebben en dat zou een op deze manier bevestigd dan wel ontkracht kunnen worden.
Met VLC net als met de Amino is het steevast na 5 minuten uit met de pret. Het (multicast-)signaal houdt op, en alleen zappen/herstarten lijkt het weer op gang te brengen.
