Waarom het voor de een snel werkt, en voor de ander traag is nu minder een functie van het kastje, maar meer de performance van de server en de verbinding daar naartoe.

Volgens mij  wordt de gids niet meer locaal ge’cached’, dus voor elke toetsaanslag in de gids moet informatie bij een server opgehaald worden.

Naarmate meer mensen op het nieuwe platform komen, zullen de servers het ook nog drukker krijgen, en dat zal de gids vast niet sneller maken.

Daarom geloof ik niet dat een firmware update dit op gaat lossen, het is een platform keuze fout.

De implementatie moet terug naar de gids locaal ‘cachen’.

Maar ik ben bang dat KPN alleen gaat luisteren als klanten massaal opzeggen,

Zelfs al was dat zo, dan nog is de hoeveelheid informatie die voor zo'n gidspagina opgehaald moet worden twee keer niets en dat zou dus absoluut niet mogen leiden tot dergelijke vertragingen.

Wat wel kan leiden tot vertraging is verkeerde routering of missende DNS entries.

Je moet er even aan wennen, persoonlijk vind ik hem mooier en beter.

Enig nadeel is dat sommige dingen nu traag reageren en met stoppen opname je het tv beeld even te zien krijgt.

Maar ik ga ervan uit dat KPN dit met een volgende update oplost.

nou @wjb ik weet het niet of de hoeveel info “twee keer niets” is. Ik heb een tijdje geleden een rekensommetje gemaakt en gepost ergens op het forum. Weet ff niet meer waar, kan zijn in het pilot-deel.

In dat sommetje ging ik voor het gemak uit van 100kb per plaatje. En dan x aantal programma's, x aantal zenders, x aantal uren, x aantal dagen terug en vooruit etc. Ik geloof dat ik toen uitkwam op iets van 4gb of 6 gb voor elke keer als je op de Gids-knop drukt. Nu is dat natuurlijk geen probleem voor een glas-verbinding, maar ik kan me voorstellen dat het ergens anders wel een probleem oplevert. Bijv. in het geheugen van een bepaald type kastje.

Zelf kom ik ook tot de conclusie dat het probleem ergens in het kastje zit. Want in mijn ene ontvanger duurt het laden v.d. gids ongeveer 3 secs. In de andere gaat het razendsnel. En ze zitten allebei op dezelfde internetverbinding (=pairbonding).

dat lijkt mij heel veel per keer bedoel je niet mb

nee, echt GB (gigabyte).

Maar het is natuurlijk onzin dat de hele gids opgehaald wordt bij het openen.

Er hoeft natuurlijk telkens maar één pagina aan programma info opgehaald te worden en het laden van afbeeldingen gaat ook nog eens asynchrone. Je hoeft dus alleen te wachten op een paar kB (één pagina programma info) en dan kan je al gaan selecteren. En als het goed is wordt die pagina ook gecached zodat die niet telkens weer opnieuw opgehaald hoeft te worden.

Zijn die TV ontvangers beide van hetzelfde type?

100mbit per sec. 

4000 zou dan 40 sec. Laden per keer zijn 

Als je 100mbit of hoger abonnement hebt 

Een tv ontvanger heeft (2260) een 100mbit poort 

Of doe ik het fout?

ik bedoel hiermee dat het nooit kan op deze manier

Vergeet die discussie over de grootte van de hele gids want zo werkt het natuurlijk niet.

Zie mijn vorige bericht.

Ik ben bang dat het geen onzin is. Een aanwijzing (niet meer dan dat) daarvoor heb ik vanuit de pilot en daar ga/mag ik niets over zeggen.

Maar misschien kan iemand het testen door te kijken naar het dataverbruik op de internetverbinding op het moment dat je de Gids opent? Dan weten we het zeker.

Mijn ontvangers zijn: VIP5202 en VIP2952v2

Daarbij komt: ik ben bij dat rekensommetje zomaar eens uitgegaan van 100kb per afbeelding. Is dus puur natte vingerwerk. Als het om 200 of 300 kb per plaatje gaat, dan hebben we het over een ver(drie)dubbeling van dat eindtotaal.

maar simpel 4 tot 6 gb per keer als je gids indrukt kan gewoon niet

ik wou het wel voor je testen met mijn fritzbox

maar ik heb het oude menu nog

dus helaas

zo dat ik deze reacties allemaal lees hou ik het liefst het oude menu zo lang mogelijk

Maar @Katana321, ik weet niet wat ze je tijdens die pilot wijsgemaakt hebben maar ik hoop dat je begrijpt dat die hoeveelheid data absoluut niet in één keer binnen gehaald hoeft te worden immers dan zou je niet praten over enkele seconden maar over een paar minuten.

Ik hoop dat je snapt dat de EPG opgehaald wordt per pagina van de gids die je benadert en dat die pagina ook gecached wordt. Plaatjes worden asynchroon opgehaald en pas nadat een bepaalde uitzending in de gids iets langer geselecteerd is zodat bij het scrollen door de uitzendingen niet elk plaatje opgehaald hoeft te worden.

Geloof me, de hoeveelheid data die per keer (gids pagina) opgehaald moet worden is echt twee keer niets en dat is dus heel weinig.

Nee, ik heb vanuit de pilot niet een bevestiging gekregen op mijn rekensom. Dus het zou zomaar kunnen dat die 4 of 6 GB onzin zijn, dat geloof ik beslist. Dus OK, akkoord. Ik ben verder ook geen techneut.

Wat ik bedoelde met die “aanwijzing”: dat er wel iets is met de hoeveelheid data. Daar zit schijnbaar toch een probleem.

Ik zou het bijzonder vinden dat er een ‘fout’ in de hoeveelheid dataverkeer zit en binnenhalen ván hoeveelheid data.

Dan zou het een geval zijn van een eigen gecreëerde DDoS en de servers gaan dan echt binnen no-time op zwart. 

Het was te warm om buiten te zitten, dus heb ik een laptopje voorzien van een tweede ethernet aansluiting, om met behulp van wiresharc eens proberen te achterhalen wat en hoe snel er iets van/naar  modem en settopbox gaat.
Ik heb een kanaal uitgekozen waar op dit moment geen uitzendig was, dus geen beeld/geluid stream die in de weg zitten.
Gids geopend en dan de wiresharc log gestart.
Toen ik 4 sec in de log zag verschijnen heb ik op de afstand bediening een ander kanaal geselecteerd in de gids (pijltje omhoog).
Nu ben ik ook een dagje ouder, dus laat ik het ruim nemen en ‘wiresharc log display’ vertraging en mijn reactietijd bij elkaar op 1 seconde stellen.
In de wiresharc log zie ik op 5.88 seconden een DNS request langs komen voor de kpn image server
Binnen een 0.001 seconden wordt het correcponderende IP adres opgestuurd.
Dan iets later zie ik 37 paketten van 1500 byte richting settopbox gaan
Laatste grote pakket heeft timestamp 6.24
Het plaatje is dus grofweg 50kb groot, en kost bijna 0.4 seconden om over te sturen.
Ervanuitgaande dat het vast weg een jpeg zal zijn, moet het kastje dit nog decoderen en op het scherm zetten.
De tijd die dit kost kan ik helaas niet makkelijk meten.

Voorlopige conclusie :
DNS en routing zal bij mij niet het probleem zijn.
0.4 seconden + onbekende decodeertijd vind ik best veel voor een 'responsive user interface'.

Twee dingen.

1) Plaatjes worden asynchroon opgehaald en daar zal je dus nooit op hoeven wachten.

2) Ik neem aan dat je 50kB bedoelt ofwel 400kb. Bij een internet snelheid van 50Mbps is dat plaatje dus al in 8 milliseconde gedownload, laat staan hoeveel tijd dat kost als je een hogere downloadsnelheid hebt.

Plaatjes worden gewoon van een server gehaald

Of je er op moet wachten op niet 

Dat is afhankelijk van de grote in die geval niet groot 

Je download ze dus wel

Uiteraard download je ze, ze moeten toch ergens vandaan komen. 

Dat downloaden van het plaatje heeft echter geen invloed op de wachttijd immers die download is asynchroon en de gids is gewoon te bedienen, ook als dat plaatje nog niet volledig gedownload is.

Wanneer gaan jullie de bugs eruit halen? Het is ontzettend traag geworden. Mini tvgids is niet meer uit te schakelen, zappen tussen 2 kanalen werkt in sommige gevallen niet. Vooralsnog ben ik geen fan van deze verandering. leuk dat het er fancy uitziet, wel ontzettend jammer dat het traag als dikke stront door een dunne trechter geworden is.

Ik dacht dat ik duidelijk neergezet had 37 * 1500 BYTE afgerond is dat 55 KILO BYTE waarvan grofweg 10% overhead, blijft er 50 KILO BYTE (jpeg?)plaatje over.
En theoretische maximale snelheden zijn leuk, sneller zal het niet gaan, maar in de praktijk ben je niet de enige gebruiker van het internet en de server.

Ik heb nog een metinkje gedaan.
TV op kanaal 661 (ned1 glas)
tegelijk (voorzover dat uit de hand kan)  wireshark gestart en op het gids knopje van de afstand bediening gedrukt.
na 0.74 seconden een DNS request naar de api server, welke vrijwel meteen 'geresolved' wordt.
na 1.01 seconden de eerste datablokken van de api server.
na 1,37 seconden het laatste api pakket
na 2.02 seconden een DNS request voor de image server
    er volgen 15 blokken van 1500 byte zal dus iets van 20 kilobyte zijn.
na 2.12 seconden het laatste image pakket

Geen timing waar ik vrolijk van wordt, zeker niet als je de instant gids van de vorige firmware gewend bent.

In constateerde net het volgende op mijn VIP2952v2 (die de gids aanzienlijk langzamer opent dan mijn VIP5202):

-de ontvanger staat op zender 1.

Als ik op Gids druk zie ik de programma's van zender 1 t/m 8. Hij laat dan in de gids ongeveer 25 programma's zien. Het duurt ongeveer 2 seconden voordat alles op het scherm staat.

-de ontvanger staat op zender 1475.

Als ik op Gids druk zie ik de programma's van de laatste 3 zenders. Hij laat dan in de gids 3 programma's zien. Het duurt ongeveer 1 seconde voordat alles op het scherm staat.

Dus het laden van de gids duurde dus 0,63 seconde en dan kan je de gids dus bedienen, de wachttijd is voorbij. Het plaatje komt asynchroon en speelt geen enkele rol in de wachttijd, de gids is dan al volledig operationeel.

Fout, de data overdracht van de api server naar het kastje koste 0.63 seconden, hoe lang het kastje erover doet om het op het scherm te zetten weet ik niet, kan ik niet meten, maar dat zal geen 0.0 seconden zijn.

Maar jij vergeet even dat er al 0.74 seconden verlopen zijn tussen op de gids knop drukken en het eerste request uit het doosje naar de api server.

Ik ben vast wel wat ouderwets, maar als ik op een knop druk wil ik een respons zien.

En een scherm wat in brokken opgebouwd wordt geeft mij de indruk dat het sloom en stroperig gaat.

Het moet er meteen compleet staan, en wel vrij snel na het indrukken van een knop, anders heb je een slechte user interface gemaakt.

Die 2,12 sec komt overeen met wat ik nu zie op de VIP2952v2. Maar dat is dan als ik de ontvanger op zender 1 heb staan. (Zet ik de ontvanger op de laatste zender, dan gaat het aanzienlijk sneller. Zie bovenstaande post.)

Overigens is dat al sneller dan ten tijde van de pilot. Toen ging het over zeker 3 seconden. De techneut van kpn die toen mijn ervaringen heeft onderzocht en gemeten, kwam zelfs op 4 seconden.

Interessant die metingen. Vraagje @gdf, heb jij niet toevallig 2 verschillende types tv-ontvangers?