De gemakkelijkste oplossing is gewoon een andere client gebruiken voor het bekijken van de video,
maar daar is het achterliggende probleem nog niet mee opgelost rond het specificatie support op banned.video.

Waar wringt het precies met de nu geldende standaarden op chrome-achtige browsers?

#sockpuppet

Als het probleem niet te reproduceren is, kan het ook gaan om een tijdelijke fout. Bijvoorbeeld dat de tor verbinding te langzaam was om de video bij te houden o.i.d.

Als het vaker voorkomt zou ik de oorzaak zoeken in:
1) Een mismatch tussen de getoonde user-agent en de echt gebruikte webbrowser. Er zitten wat verschillen tussen webbrowsers (https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement#Browser_compatibility) wat zou kunnen leiden tot het idee dat iemand ondersteund zou moeten zijn (op basis van de user-agent) terwijl dat niet het geval is in de gebruike browser.
2) Extra privacy/veiligheidsmaatregelen van Brave in 'tor mode' waardoor bepaalde functies zijn uitgeschakeld.

Via Control+Shift+I zie ik een bandbreedte probleem (een websocket handshake met een 403) en switchen naar een andere streaming agent. Het begint eerst met een alert over twee maal niet verbinding kunnen maken met Google Analytics.

Vreemd omdat het bij het banned video kanaal toch de bedoeling moet zijn een alternatief te bieden voor video's die verbannen zijn van Google's YouTube platform. Daar verwacht je dus zeker niet deze Google Analytics tracking. Maar ja een heleboel zaken zijn in feite niet, zoals ze voorgesteld worden. Valt men op deze manier toch daar weer eens lekker door de mand naar het schijnt. Het ene beweren en het andere gecontroleerd aan het doen zijn.

sockpuppet

Als ik zoek op je foutmelding dan kom ik vermeldingen tegen waar net iets anders in staat:
Kan het zijn dat je iets niet goed hebt overgetypt?

Deze fout komt uit videojs, een videospeler die in Javascript is geïmplementeerd die kennelijk door zo'n 400.000 websites wordt gebruikt. De speler draait in je browser, en de fout wordt daarin geconstateerd, en niet door de website afgegeven. Ik ga niet pretenderen dat ik door vluchtig te kijken alles snap wat in de verschillende vermeldingen tegenkom, maar het lijkt te kunnen liggen aan onregelmatigheden als gecorrumpeerde data in de videostroom. Dat kan natuurlijk incidenteel voorkomen.

Een buffer is niet meer dan een stuk werkgeheugen dat gebruikt wordt om verschillen op te vangen tussen (in dit geval) het tempo waarin de data van de video over de lijn binnenkomt en het tempo waarin de speler de data bij het afspelen consumeert. De foutmelding zoals ik hem heb staan wekt op mij de indruk dat de bufferlogica weigert verder te werken als er een andere fout is opgetreden (en ik zag ook ergens een andere fout als vermoedelijke oorzaak genoemd worden). Zonder nadere informatie is het onmogelijk om te weten wat die andere fout dan geweest is. Het is mogelijk dat dit een bug in videojs is, als het de bedoeling is dat dergelijke fouten zijn opgevangen voordat de bufferlogica constateert dat dat niet zo is.

Je geeft zelf aan dat de fout niet optreedt bij opnieuw afspelen. Daarmee beantwoord je eigenlijk zelf al je vragen over browsers en api-problemen: als dat het was was de fout blijven optreden, dat is het dus niet.

Je werkt over TOR, wat betekent dat de datapakketjes langs heel wat meer hosts worden geleid dan bij een rechtstreekse verbinding met de server. Een langere weg met meer tussenstappen verhoogt de kans dat er ergens iets niet goed overkomt, of dat de pijplijn van TOR-nodes het benodigde tempo niet kan bijbenen. Ik vermoed dat een verhoogde kans op onvolkomenheden inherent is aan video afspelen over TOR.

Heb het nu teruggebracht tot een CSP probleem vanwege een blob 'worker-src-none' policy
-https://goo.gl/LdLk22 produceert een interrupt vanwege een DOM-Uitzondering met een "call to pause".

luntrus