Skip to main content

Slechte verbinding bij livestream (Twitch)


Toon eerste reactie

187 reacties

  • heeft eerste post geplaatst
  • January 14, 2026

Zelfde probleem hier, Ik heb 2Gbps en een logo.png Zyxel EX5601-T1… DNS al geprobeerd Dos uitgezet niks lijkt te werken...


  • is een nieuwe Poster
  • January 14, 2026

Vandaag leek redelijk, maar uiteindelijk toch lag nu. 


  • heeft eerste post geplaatst
  • January 15, 2026

Hier hetzelfde probleem. En dan bij donkaaklijn. Het maakt niet uit of ik via de app van twitch kijk met 5G of via een browser met wifi. Ik ervaar het ook alleen bij hem. Gister hebben we een poll gehouden. Van de 100 mensen die precies dezelfde klachten hadden zijn er 95 klant van ODIDO. 

 

Ik hoop dat dit opgepakt wordt door ODIDO want dit is geen kijken.

Mee eens! Bloedirritant dit. Heb hetzelfde probleem maar niet alleen bij donkaaklijn maar bij alle streamers die ik volg. 


  • January 15, 2026

Hier nog steeds dezelfde bak ellende dat streams niet goed bufferen.. en niet kijkbaar zijn. alles boven de 360p loopt uit in een bufferfest.

Wordt er uberhaupt wel onderzoek gedaan?  

Als er data nodig is,  Geef dan door wat en hoe te testen. Mss is het ook handig om postcode gebieden of wat dan ook te gaan matchen..

Hier iig Harderwijk.


  • is een Top Poster
  • January 15, 2026

Streams bekeken:

https://www.twitch.tv/missmikkaa
https://www.twitch.tv/juliakins


37.143.84.228 + 62.58.48.20 DNS vanaf ISP(na herstart router) gelijk issues bufferen:


Met 1.1.1.1 + 1.0.0.1 DNS geen issues:

Wat ook raar is dat de geschatte bandbreedte met 37.143.84.228 + 62.58.48.20 DNS ingesteld veel lager is dan met 1.1.1.1 dan zie je 300 - 400Mbps voorbij komen.
 

Met 1.1.1.1 + 1.0.0.1 DNS:
 

 


rvk01
  • January 16, 2026

Streams bekeken:

https://www.twitch.tv/missmikkaa
https://www.twitch.tv/juliakins


37.143.84.228 + 62.58.48.20 DNS vanaf ISP(na herstart router) gelijk issues bufferen:


Met 1.1.1.1 + 1.0.0.1 DNS geen issues:

Wat ook raar is dat de geschatte bandbreedte met 37.143.84.228 + 62.58.48.20 DNS ingesteld veel lager is dan met 1.1.1.1 dan zie je 300 - 400Mbps voorbij komen.

Wat ik dus zo raar vind is dat de routes hierboven identiek zijn. Hier zou de DNS server verder geen effect meer mogen hebben. Een ping rechtstreeks naar die hops zou direct via de gateway gaan en DNS instellingen zijn dan niet meer van belang.

Ik denk dat die iets hogere maximale ping dan ook niet de oorzaak is van dit probleem. Het “gemiddelde” bij de 1.1.1.1 server is immers ook hoger dan die van de ISP.

Maar welk IP onderzoek je nu uiteindelijk? Als ik naar de daadwerkelijke streams kijk dan zie ik dat deze met 2 seconden blokjes van een cloudfront server komen. b.v. ed42b80a927c.j.cloudfront.hls.ttvnw.net. En die resolved naar 18.239.69.90. Dat is een hele andere dan b.v. 151.101.66.167. Pak je dan wel het goede IP om te onderzoeken? Die 151.101.66.167 is volgens mij absoluut niet het IP waar de stream zelf vandaan komt.

 


  • is een Top Poster
  • January 16, 2026

Ik onderzocht twitch.tv inderdaad.

Maar ik tel minstens 10 verbindingen naar cloudfront bij het kijken naar 1 stream.
https://www.twitch.tv/missmikkaa

Als ik een willekeurige pak: 18.239.36.90 server-18-239-36-90.ams58.r.cloudfront.net
Met 1.1.1.1 1.0.0.1 DNS zonder buffer issues:
 

 

Met 37.143.84.228 + 62.58.48.20 DNS ingesteld:



 

 


rvk01
  • January 16, 2026

Als ik een willekeurige pak: 18.239.36.90 server-18-239-36-90.ams58.r.cloudfront.net

Met 1.1.1.1 1.0.0.1 DNS zonder buffer issues:

En als je f12 gebruikt op Chrome dan zie je welk verkeer dat allemaal is. Elke 2 seconden een tekstbestand met aantal urls met stream data en vervolgens die data elke 2 seconden weer een request. Ik vond dit al een redelijk inefficiënte manier voor een stream maar schijnbaar werkt twitch zo.

De vraag is dus of je daar ook rare dingen ziet (fouten/weigeringen)?

 


  • is een Top Poster
  • January 16, 2026

Als ik een willekeurige pak: 18.239.36.90 server-18-239-36-90.ams58.r.cloudfront.net

Met 1.1.1.1 1.0.0.1 DNS zonder buffer issues:

En als je f12 gebruikt op Chrome dan zie je welk verkeer dat allemaal is. Elke 2 seconden een tekstbestand met aantal urls met stream data en vervolgens die data elke 2 seconden weer een request. Ik vond dit al een redelijk inefficiënte manier voor een stream maar schijnbaar werkt twitch zo.

De vraag is dus of je daar ook rare dingen ziet (fouten/weigeringen)?

 

Hij is weer aan het bufferen, te zien aan het rond draaiend cirkeltje:
Maar ik weet niet precies waar ik dat tekst bestandje kan vinden.

 

 


rvk01
  • January 16, 2026

Hij is weer aan het bufferen, te zien aan het rond draaiend cirkeltje:
Maar ik weet niet precies waar ik dat tekst bestandje kan vinden.

 

Je ziet dat in de console ook nogal wat foutmeldingen staan (foutmeldingen van de source van Twitch en netwerkproblemen?).

De urls staan in de tab netwerk. Die staat onder dat pijltje rechts van Console en Source tab. Als je die developer tools ontkoppeld van het hoofdscherm dan heb je meer ruimte om te zien wat er allemaal gebeurd (Chrome en Brave geven dit al standaard los, Edge niet).

 


  • is een Top Poster
  • January 16, 2026

Hij is weer aan het bufferen, te zien aan het rond draaiend cirkeltje:
Maar ik weet niet precies waar ik dat tekst bestandje kan vinden.

 

Je ziet dat in de console ook nogal wat foutmeldingen staan (foutmeldingen van de source van Twitch en netwerkproblemen?).

De urls staan in de tab netwerk. Die staat onder dat pijltje rechts van Console en Source tab. Als je die developer tools ontkoppeld van het hoofdscherm dan heb je meer ruimte om te zien wat er allemaal gebeurd (Chrome en Brave geven dit al standaard los, Edge niet).

 

ik zie nu dit:
Hoe kan ik zien of er issues mee zijn?
 

 


rvk01
  • January 16, 2026

ik zie nu dit:
Hoe kan ik zien of er issues mee zijn?

 

Op zich ziet dat er redelijk uit. Je kunt ook de inhoud zelf bekijken en die van 9kb is volgens mij een tekstbestand met urls van bestanden van 2 seconden per bestand. Die andere 2MB files zijn dan de inhoud van de stream. Dat ziet er dus redelijk uit MAAR... ik zie er daar 1 van 9,22s terwijl de andere allemaal in 33ms binnen zijn. 

Je zou dus even kunnen kijken of dat vaker gebeurd en welke url dat precies is. Kun je zien door die regel te kopiëren (en te kiezen voor url).

 


  • is een Top Poster
  • January 16, 2026

ik zie nu dit:
Hoe kan ik zien of er issues mee zijn?

 

Op zich ziet dat er redelijk uit. Je kunt ook de inhoud zelf bekijken en die van 9kb is volgens mij een tekstbestand met urls van bestanden van 2 seconden per bestand. Die andere 2MB files zijn dan de inhoud van de stream. Dat ziet er dus redelijk uit MAAR... ik zie er daar 1 van 9,22s terwijl de andere allemaal in 33ms binnen zijn. 

Je zou dus even kunnen kijken of dat vaker gebeurd en welke url dat precies is. Kun je zien door die regel te kopiëren (en te kiezen voor url).

 

Ah zo, nu snap ik het, thanks.
ja dat zie ik heel vaak gebeuren, soms 9 sec.
Dit is er een van 6 sec:

 


  • is een Top Poster
  • January 16, 2026

Zie voornamelijk dat die Cvg segmenten na de m3u8 van rond de 2MB langer duren, waarschijnlijk door de grootte.

 


Sommige canceled: 
zoals https://9c6ee9e29d42.j.cloudfront.hls.ttvnw.net/v1/segment/Cvg

 

buffer + netwerk video


  • is een Top Poster
  • January 16, 2026

 

 

 


rvk01
  • January 16, 2026

Dat lijkt mij inderdaad niet goed. Op mijn KPN abonnement geeft ie dit.

~ $ nslookup 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net 192.168.2.1
Server: 192.168.2.1
Address: 192.168.2.1#53

Non-authoritative answer:
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 18.238.243.112
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 18.238.243.76
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 18.238.243.13
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 18.238.243.27
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:d200:4:74ec:2100:93a1
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:5000:4:74ec:2100:93a1
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:da00:4:74ec:2100:93a1
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:6400:4:74ec:2100:93a1
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:b000:4:74ec:2100:93a1
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:9600:4:74ec:2100:93a1
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:6800:4:74ec:2100:93a1
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:7a00:4:74ec:2100:93a1

Dat kan wel een reden zijn dat de 1.1.1.1 goed werkt want die zal hem goed resolven. Probeer maar eens met

nslookup 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net 1.1.1.1

Dus ja. Dit zou best eens de oorzaak kunnen zijn. Een verkeerd gedeelte in de Odido DNS servers.

Zou dat dan voor alle "j." in de *.cloudfront.hls.ttvnw.net gelden?


  • is een Top Poster
  • January 16, 2026

Hmm interesting. veel ipv6 dan ook ineens

 

Een tweede op .j met buffer problemen hetzelfde inderdaad:
 

 


rvk01
  • January 16, 2026

Hmm interesting. veel ipv6 dan ook ineens

Een nslookup geeft ook IPv6 terug, ook als dat niet aan staat. Dus die kun je negeren bij Odido 😉

Je ziet dat de 1.1.1.1 wel goed resolved maar de DNS van Odido niet. Ik vraag me af of alle foute urls die je ziet die j. hebben?

Maar hier kunnen ze bij Odido in ieder geval wel wat mee. ​@Odido ​@Tommie van Odido ?


  • is een Top Poster
  • January 16, 2026

In ieder geval met een 2e ook van een andere stream met buffer issues:

https://www.twitch.tv/bonnie

C:\Users\Richard>nslookup 7325bab210ad.j.cloudfront.hls.ttvnw.net
Server:  public-dns-primary.glasoperator.nl
Address:  37.143.84.228

Non-authoritative answer:
Name:    7325bab210ad.j.cloudfront.hls.ttvnw.net
Addresses:  2a02:4240::6f
          37.143.87.93


C:\Users\Richard>nslookup 7325bab210ad.j.cloudfront.hls.ttvnw.net 62.58.48.20
Server:  public-dns-secondary.glasoperator.nl
Address:  62.58.48.20

Non-authoritative answer:
Name:    7325bab210ad.j.cloudfront.hls.ttvnw.net
Addresses:  2a02:4240::6f
          37.143.87.93


C:\Users\Richard>nslookup 7325bab210ad.j.cloudfront.hls.ttvnw.net 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    7325bab210ad.j.cloudfront.hls.ttvnw.net
Addresses:  2600:9000:20a0:3400:1e:56a1:e000:93a1
          2600:9000:20a0:4800:1e:56a1:e000:93a1
          2600:9000:20a0:1000:1e:56a1:e000:93a1
          2600:9000:20a0:fc00:1e:56a1:e000:93a1
          2600:9000:20a0:4e00:1e:56a1:e000:93a1
          2600:9000:20a0:a600:1e:56a1:e000:93a1
          2600:9000:20a0:ba00:1e:56a1:e000:93a1
          2600:9000:20a0:f400:1e:56a1:e000:93a1
          18.239.36.50
          18.239.36.77
          18.239.36.111
          18.239.36.31


C:\Users\Richard>nslookup 7325bab210ad.j.cloudfront.hls.ttvnw.net 1.0.0.1
Server:  one.one.one.one
Address:  1.0.0.1

Non-authoritative answer:
Name:    7325bab210ad.j.cloudfront.hls.ttvnw.net
Addresses:  2600:9000:20a0:ac00:1e:56a1:e000:93a1
          2600:9000:20a0:c800:1e:56a1:e000:93a1
          2600:9000:20a0:6e00:1e:56a1:e000:93a1
          2600:9000:20a0:2e00:1e:56a1:e000:93a1
          2600:9000:20a0:8800:1e:56a1:e000:93a1
          2600:9000:20a0:b600:1e:56a1:e000:93a1
          2600:9000:20a0:b200:1e:56a1:e000:93a1
          2600:9000:20a0:4e00:1e:56a1:e000:93a1
          18.239.36.50
          18.239.36.77
          18.239.36.31
          18.239.36.111


  • is een Top Poster
  • January 17, 2026

Ik heb sinds gisteren geen problemen meer. Dacht eerst dat het toeval was, maar na lezen van hierboven gemelde problemen met de dns en cloudfront kan het komen doordat ik overgegaan ben naar een andere blocklist in mijn ublock origin (“oisd big” heet die lijst. Staan naast 200k+ blocks ook 40+ “j.cloudfront” en andere “cloudfront” regels in).

Kan toeval zijn, maar lijkt in mijn geval te werken


rvk01
  • January 17, 2026

Ik heb sinds gisteren geen problemen meer. Dacht eerst dat het toeval was, maar na lezen van hierboven gemelde problemen met de dns en cloudfront kan het komen doordat ik overgegaan ben naar een andere blocklist in mijn ublock origin (“oisd big” heet die lijst. Staan naast 200k+ blocks ook 40+ “j.cloudfront” en andere “cloudfront” regels in).

Kan toeval zijn, maar lijkt in mijn geval te werken

Nu zal Odido zelf niet werken met een blocklist op hun DNS en aangezien hier ook nslookup faalt (die buiten ublock van de browser werkt) zal het dus denk ik wel een config probleem zijn. Ik neem even aan dat jullie allemaal geen Thuis Veilig Online (TVO) hebben van Odido? (Het pakket wat op de router draait)


  • is een Top Poster
  • January 17, 2026

Ik heb sinds gisteren geen problemen meer. Dacht eerst dat het toeval was, maar na lezen van hierboven gemelde problemen met de dns en cloudfront kan het komen doordat ik overgegaan ben naar een andere blocklist in mijn ublock origin (“oisd big” heet die lijst. Staan naast 200k+ blocks ook 40+ “j.cloudfront” en andere “cloudfront” regels in).

Kan toeval zijn, maar lijkt in mijn geval te werken

Nu zal Odido zelf niet werken met een blocklist op hun DNS en aangezien hier ook nslookup faalt (die buiten ublock van de browser werkt) zal het dus denk ik wel een config probleem zijn. Ik neem even aan dat jullie allemaal geen Thuis Veilig Online (TVO) hebben van Odido? (Het pakket wat op de router draait)

Geen TVO gebruiker hier.

 

 

Zie ook een beetje wanneer het zich voordoet:
Wanneer dit voorbij komt van 30sec.:
AUTZ_DISALLOWED_BITRATE miss from cloudfront
dan vertraagd al het verkeer daarna met 1-10 sec.

Sommige .j zijn wel te resolven op 37.143.84.228 + 62.58.48.20

76553a7dc934.j.cloudfront.hls.ttvnw.net

545a6fa5e369.j.cloudfront.hls.ttvnw.net

 

 


  • is een Top Poster
  • January 17, 2026

Had dit in de Chrome staan (bij (privacy and security).


Mensen die het probleem niet kunnen reproduceren op:
https://www.twitch.tv/missmikkaa

Welke deze url gebruikt: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net

Hebben misschien daar cloudflare/OpenDNS staan i.p.v. OS default.

 

Wat ik ook vreemd vind is dat google ook 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net als 37.143.87.93 resolved:
 

 


rvk01
  • January 17, 2026

Wat ik ook vreemd vind is dat google ook 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net als 37.143.87.93 resolved:

Dat is wel heel maf. Op mijn KPN abonnement resolved Google hem goed. Op mijn Linux machine:

~ $ nslookup 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 18.238.243.27
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 18.238.243.76
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 18.238.243.13
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 18.238.243.112
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:600:4:74ec:2100:93a1
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:f000:4:74ec:2100:93a1
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:8e00:4:74ec:2100:93a1
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:b000:4:74ec:2100:93a1
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:4200:4:74ec:2100:93a1
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:2c00:4:74ec:2100:93a1
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:9200:4:74ec:2100:93a1
Name: 9c6ee9e29d42.j.cloudfront.hls.ttvnw.net
Address: 2600:9000:2090:4000:4:74ec:2100:93a1

Die 3.171.212.0/22 is een load balancer van CloudFront maar ik krijg bij 1.1.1.1 toch ook consequent het 18. adres.

 


rvk01
  • January 17, 2026

Wacht... Heeft Amazon een load balancer binnen het Odido netwerk staan? Dan klopt het wel dat Google DNS daarnaartoe verwijst.

Maar als die load balancer problemen heeft.…

Gegevens van Censys. Misschien is er dus wel een probleem met die load balancer.

Voor diegene die nog problemen heeft... gebruik niet 8.8.8.8 als DNS server maar 1.1.1.1 of een andere waarvan je ziet dat die naar 38. verwijst.