Ik weet niet wat er in de nacht van 18 op 19 september zogenaamd “geüpdatet” zou moeten zijn…
De amino nog maar eens van stal gehaald. En nadat eerst Omroep Brabant een keer blokkeerde en daarna VRT1 drie keer blokkeerde hebben we hem maar weer uitgezet en gaan opnieuw naar de Chromecast.
Hoe is het toch mogelijk dat Canal Digitaal er maar niet in slaagt om een betrouwbare streaming te leveren op die zenders. De Chromecast TV doet het gewoon beter omdat hij TCP gebruikt. Het zou erg fijn zijn als dat voor de live stream ook met de amino zou mogelijk gemaakt worden…
Amino: Het was niks, het is niks en het zal ook nooit wat worden.
Het is gewoon troep. Bij ons staat hij uit. Ik ga het gewoon niet meer proberen. Weggegooid geld, slecht voor het millieu.
1 like
Het Amino kastje doet het hier wel. Sinds enkele rampzalige updates geleden lijkt de software nu wel enigszins bruikbaar voor wat wij gebruiken. Het probleem is met de data-stream. CD slaagt er maar niet in om een continue data-stream onze kant op te krijgen bij bepaalde zenders, vooral bij de VRT (VRT1 en Canvas). Al meer dan een jaar lang wordt de stream onderbroken kort voor het einde van een programma (en komt dan na een minuut of zo weer op gang). Dit tijdstip lijkt samen te vallen met het begin van het starten van opname en begin-gemist server acties bij CD. Het lijkt erop dat ze te weinig server capaciteit hebben om de lopende stroom te laten doorlopen en tegelijk nieuwe opnames te beginnen. Ik neem aan dat de servers voor verschillende zenders ook verschillend zijn (alles tegelijk is teveel gevraagd voor één server). NPO zenders hebben dit probleem niet, ondanks dat ze een hogere bandbreedte gebruiken dan VRT (of lokale omroepen zoals Omroep Brabant). Wij kunnen tegenwoordig probleemloos met de amino naar de NPO zenders kijken (en de weinige RTL of Talpa zenders die bij ons wel eens even aan staan). Het probleem is vooral met de VRT streams, en ik kan mij moeilijk voorstellen dat dit aan het Amino kastje ligt.
Elke keer als er weer eens een “update” wordt aangekondigd krijg ik weer even hoop… maar al snel blijkt dat het tevergeefs is.
De zenders die ik kijk zijn probleemloos.
Dat de uitzending gemist soms raar doet, is gewoon gebleven.
VRT kijk ik nooit.
Merkte wel, dat ik door terug te spoelen in een live uitzending ik vloeiend in gemist kwam.
Bij een 2e poging om deze feature te gebruiken, ging het al mis.
Dan denk ik, niet gebruiken. Dan erger ik me ook niet.
Ik mis wel bij een aankondiging van Freedom over deze update, een uitleg wat er veranderd is.
1 like
Sws zou het fijner zijn dat er uitleg komt bij updates ipv het altijd maar aanwezig onderhoud of niet nader genoemde verbeteringen.
Risico is dan natuurlijk weer dat gebruikers inhoudelijk (kunnen) gaan discussiëren of een effect verifiëren.
1 like
Kan het zijn dat de problemen door iets anders veroorzaakt worden dan de Amino?
Ik herken de genoemde problemen niet meer!
Nou, dat kan zeker, en aangezien het bij mij thuis met NPO zenders (met hogere bandbreedte) feilloos werkt en met VRT hapert lijkt het mij dat er bij het genereren van de stream haperingen komen wanneer een programma bijna afgelopen is. Als je de problemen wil herkennen moet je VRT1 opzetten, of ook Omroep Brabant.
Zeer goed mogelijk dat het komt door welk netwerkpad het transport precies verloopt.
Dat anderen geen storingen ervaren kan weer komen omdat een probleem net onder de radar van waarneming blijft. Ook in de aanlevering kan al een bron van een uiteindelijke oorzaak zitten.
Wij kijken zelf vooral satelliet en ook daar zijn er behoorlijk verschillen in transponders, datalrate, kwaliteit en sterkte. Met regen of een onweerwolk, stort het vaak helemaal in.
Op zeg een SD kanaal met weinig bewegend beeld is er dan bv prima naar te kijken maar zodra het snelwisselend HD4K is, gaat het irritant pixelen en stotteren.
Probleem met beeld/geluid is dat je daar absoluut geen haperingen wilt, iets dat dan weer is op te lossen (door de uitzender of apparatuur) door de latencybuffer maar flink op(en) schroeven.
Kennelijk heeft iets/iemand iets snel opgepakt en stilletjes gecorrigeerd… waarvoor dank.
Door in de alias lijst op de puntjes te clicken is daar een keuze op/nee sorteren bijgekomen. Tot gisteren, kon je daarmee alleen de kolom verbergen.
(Beetje jammer is dat dit - nog - in het Engels is vermeld. Doe alles Nederlands of Engels maar ga niet steencoalen omdat dit zo makkelijk stookt.).
Helaas moet ook nog steeds, voortdurend naar beneden worden gebladerd om de volledige aliassenlijst te zien te krijgen.
VRT1 en 2 kijken we regelmatig zonder problemen, opgenomen programma’s starten ook nauwkeuriger vergeleken met enige maanden geleden.
Interessant… Vreemd dat bij ons toch altijd het einde (vaak de aftiteling) van een programma is waarbij de stream hapert. Het maakt verder niet uit hoe lang het programma is: het blijft gewoon werken, tot bijna het einde. Bijvoorbeeld: Flikken (Gent) net vóór het korte nieuws van 18:05, of ook Thuis (begint zo rond 20:15). Maar ook andere programma’s. Het is altijd wanneer server het druk krijgt, omdat hij de stream van het volgende programma moet starten terwijl die van het huidige programma nog even moet blijven door lopen. Dan moet de server dus even dubbel werk doen, en precies dan hapert de stream. Dat kan toch niet aan mijn netwerk thuis of aan de Amino liggen? De minste hapering in een UDP verbinding is natuurlijk al genoeg om de stream even te doen stoppen (voor ca. een minuut).
Vreemd ook dat het is bij zenders die een stream hebben van 6 a 7 Mbps en juist niet bij zenders met een stream van hogere bandbreedte… Ik snap het niet.
(Maar door een Chromecast TV te gebruiken of de app op de computer heb je altijd een TCP verbinding en dan is er geen probleem.)
Het ligt imo niet zozeer aan de server maar dat client-hard/software thuis niet goed omgaat met (redundante) buffering. Iets dat kan komen door te weinig “geheugen”, rommelige software of prioritering (cq QoS of classificatie) van datastromen.
Streams met een hogere (kwalitatieve) bandbreedte, zullen doorgaans meer bufferen wat dan resulteert in een “stabieler” beeld. Technisch betekent dat niet dat het daarmee allemaal OK is; de kijker merkt alleen niets van eventuele (achtergrond) problemen.
Het te gebruiken protocol (UDP/TCP) helpt zaken te verbeteren waarbij TCP weer meer (retry)netwerkbelasting geeft dan UDP. Chromecasten kan weer andere (privacy?) merites opleveren.
Om het goed te snappen zou de streamdata met hard & software tot op byte niveau E2E moeten worden gedecodeerd om vervolgens te worden geanalyseerd om vervolgens proberen te begrijpen waar het fout gaat.
Ik snap het niet goed. Als de “client-hard/software thuis niet goed omgaat met (redundante) buffering” dan zouden haperingen toch min of meer willekeurig wanneer moeten optreden? Hoe kan het aan de client liggen dat de stream steeds een paar minuten voor het einde van een programma (volgens de programmagids) hapert en niet op andere momenten? Bij het kijken naar een live stream weet de client toch helemaal niet wanneer een programma gaat eindigen of beginnen? Het loopt immers gewoon altijd door. (En de stream hapert niet aan het einde van het programma maar een paar minuten daarvoor.)
Enfin, tot er nog weer eens een update komt staat de Amino bij ons weer gewoon uit.
Ik kan van alles bedenken en de vraag is ook een beetje of en waaraan je het zelf (wilt) wijten. Dingen uitleggen verzand al gauw in ingewikkelde verhalen die verder niets zullen oplossen.
Ik gok dat programma streams (intern gestuurd of zo aangeboden) moeten overschakelen. De lopende stream moeten worden afgewerkt en tegelijkertijd moet er een nieuwe - via een ander parallel process qua buffer - op gang komen.
Kern is dat het hele opzet van TV aanbieden over/op andermans netwerk, in de basis op tal van manieren - oorzakelijk - fout kan gaan.
Dit los van geeconomiseerde el-cheapo kastjes en krakkemikkige (software) techniek. Ik heb zelf vooral het idee dat dingen in de burelen vooral een kosten/baten afweging zijn: als maar 0.1% serieus klaagt is daarmee dus 99,9% “blij”. Het voor die paar duizend “klagers” verbeteren, wordt dan een financiële afweging.
Wat ik al wel heb gedaan is op de fritzbox kijken naar de internet monitor.
De stream valt plots helemaal weg, en na een minuutje of zo begint hij weer. De amino kan natuurlijk niets doen zolang er geen data binnenkomt. De vraag is: waarom valt de stream stil? Het is echt niet dat de lopende stream moet worden afgewerkt en tegelijk een nieuwe op gang komen want dat zou kunnen gebeuren in de overgang van een programma naar een volgende programma, maar de hapering is altijd zo’n vijf minuten voordat die overgang moet plaats hebben. Na een minuutje start de stream weer op (wat sneller als je even naar een andere zender gaat en dan weer terug) en wanneer het programma dan echt afgelopen is en het volgende begint is er helemaal geen hapering…
De Amino doet dus wat en vraagt geen stream omdat “weet ik veel”, ergens mee bezig is dat die anders niet moet doen. De gedachte dat iets, anders dan de server of de client, zomaar stil gaat staan; is voor mij niet aannemelijk.
Verder kunnen we ons afvragen wat we (ervan) willen met als resultante dat de boel crap is. Mijn verhaal over buffers is hoe het deep-down inside werkt met streaming: hoe meer buffer en redundantie hoe kleiner de kans dat iets stilvalt.
De vraag is ook of -en in hoeverre jouw Amino (met firmware) parallele processen kan verwerken. Mogelijk dat meta-informatie van een volgende programma, dan een lopend stream afbreekt.
De enige die antwoord kan geven is: CD ism Feedm en jou, om op de knoopunten (server, router-netwerk, bras, fritz en Amino) een packet trace te draaien en dat in relatie tot ander logging onderzoeken. De kans dat ze dat - voor jou (of mij) - gaan doen, acht ik klein en blijft de bal dus aan jouw kant rollen.
Over welke stream heb je het, de bruine of de gele?
In deze grafiek zie je tvgids(-90) dan live tv kanaal 200(-60) dan NPO2 live(-40) en dan uitzending gemist.
Op 200 was op dat moment een bagger verbinding met een commissie in de 2e kamer.
De bruine is IPTV en de gele in principe gewoon internet.
Ik heb het over de bruine. Die is steady op iets minder dan 7Mbps bij VRT1 en dan gaat hij ineens naar nul en dat blijft een minuut of zo en dan springt hij weer naar boven.
De bruine zou constant moeten zijn.
Zie je dan ook activiteit in het geel of lichtbruin op dat moment?
Je zou ook even support data kunnen genereren in de fritzbox op dat moment.
Als er iets weg valt, zou dat dan in de log moeten staan.
Als ik dit doe, toets ik *99# op de telefoon en krijg dan een email.
Dat vind ik makkelijker als inloggen.
Plots wegvallen van een multicast-stream kan dat duiden op een onjuiste IGMP configuratie (fast leave) in het access- en/of thuis-netwerk. Fast leave is bedoeld voor zeer specifieke situaties en is vrijwel altijd ongewenst in geval van IP-TV.
Na enige tijd stuurt de STB wel weer een ‘membership report’ en dan gaat multicast-stream weer lopen. Van kanaal wisselen heeft hetzelfde effect.
Dat zou een zaak voor de helpdesk zijn.
1 like