Webbspelaren kraschar
Hej,
Jag lyssnar mycket via webbspelaren och den hänger sig ofta. Jag använder chrome och det rör nästan uteslutande P3 live-radio. Jag upplever att problemet är nytt men det skulle jag inte ta gift på.
Effekten är att ljudet slutar spelas, och det löses med en omladdning eller att pausa och starta uppspelningen.
Jag är osäker på varför men grundproblemet uppstår men som ni kan se i bilden så smäller javascriptet när data.context.url används. I mitt läge finns inget data.context. Det kanske är så att strömningen hade överlevt om javascriptet inte small? 
Följ inlägget
0
följare
Är det Windows eller MacOS du använder?
mvh
Windows 10 och i Chrome. Bilderna är från hls-store.js
Kan tillägga att det uppstår efter "en liten stund" av lyssning, ibland några minuter, ibland 15-20 minuter.
Det är några fler som rapporterat stopp, men det har varit svårt att se något mönster än.
Har du spelaren uppfälld eller är det bara 'lilla' spelaren?
Och navigerar du när det händer eller står sidan bara och spelar?
mvh
Jag startar spelaren direkt från högermenyn på startsidan https://sverigesradio.se/. Den körs då i nederkant av fönstret (osäker på om det är uppfälld eller lilla).
Sedan kör jag det webbläsarfönstret i en egen flik i chrome i bakgrunden. Så jag använder browsern samtidigt men andra flikar. Jag upplever att radion hänger sig även om jag har radio-fliken i fokus hela tiden också.
Har du fortfarande problem med att det stannar?
mvh
Ja tyvärr, nu smäller dock inte javascriptet så spelaren stängs av snällare. Så ni kanske får data/loggning på felen då.
Det är fortfarande diffust när det sker, ibland kan jag lyssna 20 minuter, ibland 2 minuter. Jag tror att det dock spelar roll när jag lyssnar/vilket program det rör sig om. Det verkar fungera mer stabilt på kvällar och helger dock, så helt utan data på det tror jag att problemet är som störst på vardagar, morgon och eftermiddag. Så det kanske pekar på något belastningsrelaterat.
Jag installerade er windows app som jag inte märkt några problem med, så problemet är inte så kritiskt men det skulle vara skönt att slippa ha Appen, och jag tror att webbspelar-problemen uppkommit under hösten (inga bevis för det heller :P).
mvh
Jag har exakt samma problem.
Har problemet på en dator med Windows 10 där jag provat med både Crome och Edge. Kör alltid webradion i en egen flik. Spelar ingen roll om fönstret står öppet och datorn inte används till något annat.
Samma sak gäller en annan dator där jag kör Windows 7. Där har jag också provat med Firefox.
Osäker på hur länge detta varit men några månader i alla fall.
Mvh A
mvh
Har alltså provat på olika ställen.
Telia ADSL för företag
3 mobilt bredband
Fiber via ett lokalt företag
Mvh A
Jag tror inte felet är relaterat till min uppkoppling då inga andra tjänster får problem samtidigt som radion slocknar.
Den kartläggning ni två har gjort är väldigt värdefull för oss, inte minst att ni kan återskapa felet med olika uppkoppling och i olika webbläsare.
AA:
R skrev att det fungerar utan avbrott i Windows-appen. Ett annat sätt att lyssna som borde ge samma effekt är att lyssna med direktlänkar:
MP3-länkar till alla kanaler
Allvarligt fel som drabbar få
Jag och min kollega Karolina pratade om det här felet nyss. Det drabbar så pass många lyssnare att det inte är en slump. Samtidigt är ni inte så många och vi har inte lyckats återskapa detta själva. Att ni är relativt få är förstås igen tröst för er som har det här problemet, och jag hoppas att ni förstår att vi ser allvarligt på detta.
Vi arbetar för att få till en bättre loggning i vår spelare så att vi den vägen kan få en bild av felet, men det tar tid, och vi vill ju få ordning på detta snabbt!
Gemensam nämnare?
Jag tror att det finns någon gemensam nämnare hos er med felet- men den har vi inte hittat än! Det är inte kanalen, webbläsaren, uppkopplingen eller operatören - så vad är det? Ett visst antivirusprogram som fått problem med en förändring hos oss? Att ni alla bor i Spanien och går mot samma CDN?
- När ljudet har tystnat: är knappen i spelaren "play-knapp" (som den är när ljudet är pauserat) eller i "paus-knapp" (som den ser ut när ni spelar kanalen)?
- Om play-knap: "svarar" den om ni trycker på den, så att ljudet går igång direkt?
- Det går att backa upp till tre timmar i "direkt-strömmen". Uppstår detta fel om ni testar att backa? (Testa med en halv minut eller så, om ni inte vill känna er för vilsna i tiden!)
- Blir det samma fel ifall ni väljer begränsad ljudkvalitet (se min beskrivning i en annan tråd den 26 november)
- Var i världen befinner ni er? (Om Sverige, vilken kommun?)
- Använder någon av er appen Sveriges Radio Play för Android eller Ios? Ger det samma fel?
- Om Sveriges Radio Play fungerar bra, får ni detta fel på sverigesradio.se i samma mobils webbläsare?
Svara på det ni kan. Det bättre att vi får svar på det som är lätt att besvara, än att ni inte svarar alls för att ni fastnar på någon punkt.Tack för hjälp att kartlägga detta!
Jag använder windows appen mer nu då den inte hänger sig och dessutom låter det bättre, jag antar att den streamar med högre kvalité 😀 Men det är kul att felsöka!
- När ljudet har tystnat: är knappen i spelaren "play-knapp" (som den är när ljudet är pauserat) eller i "paus-knapp" (som den ser ut när ni spelar kanalen)?
- För mig ligger spelar knappen nästan alltid kvar i "spelar läge" dvs. den är en paussymbol. Detta känns inte helt konsekvent dock.
- Om play-knap: "svarar" den om ni trycker på den, så att ljudet går igång direkt?
- Jag måste då klicka två gånger -> paus, sedan play, för att den ska börja spela igen.
- Det går att backa upp till tre timmar i "direkt-strömmen". Uppstår detta fel om ni testar att backa? (Testa med en halv minut eller så, om ni inte vill känna er för vilsna i tiden!)
- Jag testade detta idag och det är lite intressant, spelaren smäller medans den buffrar men uppspelningen fortsätter tills den når punkten. Det ser ut så när jag låter chrome pausa på exceptions.
- Blir det samma fel ifall ni väljer begränsad ljudkvalitet (se min beskrivning i en annan tråd den 26 november)
- För mig blir det det.
- Var i världen befinner ni er? (Om Sverige, vilken kommun?)
- Nacka, utanför stockholm.
- Använder någon av er appen Sveriges Radio Playför Android eller Ios? Ger det samma fel?
- Jag använder appen och får inte samma fel där. Även när jag sitter på samma wifi med båda devicerna (app i mobil, spelaren på pc)
- Om Sveriges Radio Play fungerar bra, får ni detta fel på sverigesradio.sei samma mobils webbläsare?
- Jag har testat under förmiddagen och i mobilwebbläsaren fungerar det bra också. Jag ska testa om jag kan simulera en mobilwebbläsare i datorn och på så sätt undvika problemen.
Angående andra problem så har jag funderat på om det är tillägg i chrome eller andra program på datorn som stör. Men har försökt begränsa allt sådant. Jag får ju alltid en smäll/exception javascriptet på websidan när spelaren dör. Jag lyckas inte riktigt se allt i debuggern men bifogar den exception som fångas. Det är så vitt jag kan se alltid ett "manifestParsingError".I och med att det fungerar utan problem att lyssna i mobilwebbläsaren kan det ev. vara så att det är olika javascript/spelar-kod som körs i respektive enhet? Om inte så kan det kanske ligger i att pc-webbläsarna gör något annorlunda mot mobil-läsaren, eller att något stör våra webbläsare. Tex. MS Teams eller antivirus program som du säger.
Jag bifogar ett krash-objekt från imorrse.
mvh
Och du är något på spåret här!Börja med det superenkla, som dessutom ger oss mest intressant information, tror jag (enligt principen "testa att förändra en sak åt gången"):
minska bredden på webbläsarens fönster! Då skrivs sidan ut på "mobilt vis".
Alt. 1: Chrome på Windows i smalt fönster: felet uppträder inte
Om felet inte uppträder då, är vi ju verkligen något på spåret och kan koncentrera oss på skillnaderna mellan sajten i mobilt läge respektive sajt för desktop.
Karolina och de andra utvecklarna vet mer än jag om vilka skillnaderna är. Framförallt skrivs saker ut annorlunda, inte minst själva spelaren. Alltså, som du antog att det är olika javascript/spelar-kod som körs.
Alt. 2: Chrome på Windows i smalt fönster: felet går att återskapa
Om det å andra sidan inte spelar någon roll att sidan ser ut som i mobilen, på datorn smäller det även med mobilens version, kan vi stryka dessa skillnader som potentiell orsak.
Och får koncentrera oss på vad det kan vara som skiljer sig mellan "samma sajt" i din mobils respektive dators webbläsare - på samma nätverk!
Simulera mobil på dator?
Att ge oss "fel user agent" kan absolut vara intressant ifall det inte räckte med att minska bredden på spelarfönstret för att slippa felet. Berätta då gärna vad det var för mobil du lyssnade med (modell, OS och webbläsare), så kanske vi har en idé om vad du ska testa på datorn!
Det finns nämligen vissa intressanta skillnader mellan olika user agents, där vissa webbläsare (Opera och IE är de jag kommer på) får en annan variant, "fall back-versionen", av själva spelaren. Den använder andra ljudströmmar, där det exempelvis inte går att backa i direktströmmen. (För övrigt samma ljudströmmar som du får i Win-appen). Tydligaste skillnaden grafiskt är att den spelaren, medan en kanal spelas, saknar symbol för att backa.
Jämför här, Chrome till vänster och IE till höger, spelarens mobilanpassade utseende:
Om du har en mobil webbläsare (Opera?) som ger "fall back-spelaren", kan det ju vara skillnaden!
Så:
- Testa din vanliga webbläsare med smalt fönster och berätta hur det går. Oavsett om felet försvinner eller ej, ökas vår kunskap!
- Om felet inte försvann, så berätta vad du använde för mobil, webbläsare och OS där felet inte visade sig!
Skönt att äntligen vara felet på spåret ... Tack snälla för den pusselbiten.Jag har testat under några timmar så det är inga stora underlag jag har att komma med men jag tycker mig se något kul nu. Det blir lit godtyckligt för jag kan inte riktigt bevisa när det fungerar, i och med att felet är så diffust/oregelbundet.
1. Samma fel uppstår i chrome även när jag kör den i smalt/mobil-läge. Jag började notera "back-symbolen", det var ju en fiffig indikator som krävde lite mindre inspektion. Den döljs i den smala spelaren i chrome på android men förstorar man spelaren eller använder chrome på win10 så kan man backa spelaren.
Jag testade även i Edge på win 10, där får jag samma problem och det är väll chrome under huven där också.
Jag började sedan köra i IE och där får jag inte problem! Där saknas som du beskriver ovan en back-symbol och har lite andra skillnader.
Jag är lite såld på user-agent spåret.
Jag har därför testat ett tag, men inte tillräckligt, att köra chrome i som IE10's user-agent. Backsymbolen försvinner, nya val för ljudkvalité uppstår osv. så jag har fått en annan spelare.
Då hänger sig inte spelaren. Så jag tror att ni ska gräva i den spelaren som är default i chrome på windows. 😀
Jag har ju nämnt att jag får mer problem under morgon och eftermiddag också. Men mitt lyssnande är som störst då så jag har mycket mer data. Men det kanske finns någon del av felet som är prestandarelaterat.
2. Inte riktigt svar på frågan men en summering på test jag gjort:
Win 10 Chrome - Uppspelningen hänger sig
Win 10 Edge - Uppspelningen hänger sig
Win 10 IE - Uppspelningen fungerar
Win 10 Chrome i litet fönster - Uppspelningen hänger sig
Win 10 Chrome med fejkad User-Agent (till IE 10) - Uppspelningen fungerar
Android (sony xperia) Chrome - Uppspelningen fungerar
Jag ska fortsätta lyssna med spoofad user-agent från chrome och se om det fortsätter fungera.
Om HLS-strömmen har svårt att "ta sig igenom" hos vissa lyssnare efter en brandväggsuppdatering (eller svårt att renderas snabbt nog) kanske spelaren inte får förväntat svar i rätt tid och kroknar.
Eller om vi inte kan leverera ljudströmmen korrekt. Där vet jag att det uppstod en del problem med HLS-ljuden i samband med ett CDN-byte månadsskiftet september-oktober. En del "små ljudpaket" kom inte fram i "rätt skick" (typ att någon metadata om hur datan var komprimerad inte följde med), vilket ställde till stora problem för Sonos-användare, men inte samma problem på de flesta andra plattformar som kunde hantera det vi skickade ut trots bristen.
Det där CDN-bytet skedde dock några veckor innan den här typen av felanmälningar började sippra in i forumet, så just den förändringen känns inte så misstänkt, men den är ett exempel på vad vi behöver kika på, vid sidan av att det endast är HLS-spelaren som drabbas.
Oavsett vilken faktor hos oss som bidrar, ljudström eller själva spelaren, så hade fler lyssnare drabbats (och vi hade kunnat återskapa det och undersöka det) om detta var enda orsaken. Ytterligare någon faktor krävs, och det är här dina tester blir extra viktiga!
Jag nöjer mig med att kommentera tre av dina resultat:
Win 10 IE (och fejkad UA som IE) - Uppspelningen fungerar
Att IE (eller Chrome vars UA presenterar sig som IE) inte fick felet, var förväntat, men bra att vi fick det bekräftat.
Hade även den fått felet, så hade vi kunnat ringa in "vår faktor" snabbt. Ljudströmmen vore utesluten, och den gemensamma kod som finns i de två direktspelarna utan att användas när du spelar avsnitt eller ljudklipp i efterhand, är minimal.
Win 10 Chrome i litet fönster - Uppspelningen hänger sig
Synd, eftersom det både hade varit enklare att hitta "Sveriges Radio-faktorn" och är en enkel work around.
Citerar mig sjlv:Android (sony xperia) Chrome - Uppspelningen fungerar
Får du HLS-spelaren med backa-knapp (som i Chrome på Win) eller fallback-spelaren (som i IE på Win)? Med Chrome borde det vara den vanliga HLS-spelaren, eftersom Chrome på Android länge har haft stöd för den tekniken.
- Om det mot förmodan är fallback-spelaren, så hör du av dig!
- Om det är den vanliga spelaren, så felsöker vi vidare med denna kunskap
I så fall fungerar vår sajt på mobilen som den gör för majoriteten av våra lyssnare, utan problem. "Vad det nu är" som bidrar till problemet med antingen spelaren eller HLS-strömmarna, finns inte i uppkopplingen, utan lokalt.Jag skulle nog påstå att jag hade problemen i några veckor innan jag tröttnade och började rota runt, så ev. kan problemen ha uppstått där i månadsskiftet sep/okt.
Jag misstänker också att jag lyssnar på ett lite unikt (läs. bakåtsträvande :P) sätt, det kanske är rätt få som har pc-webbläsar-radion på i den utsträckningen som jag har haft. Jag tänker att sr-play och Sonos osv. används i mycket större utsträckning. Om det inte är något unikt på min dator som stör HLS, så är det kanske "användningsmönstret" som är ovanligt. Mina fördomar säger mig mitt användningsmönster är lite mer "IE-användare-typiskt" och för dem fungerar det ju.
Lite intressant ang. HLS är ju var det är supportat, både wikipedia och caniuse anger ju att det är native i android chrome men inte chrome på windows. https://caniuse.com/http-live-streaming
Om ni har implementerat en egen/3-parts klient för det i chrome så kanske det är en skillnad mellan android och windows chrome.
Det kanske skulle vara intressant att testa med en edge version innan de gick över till Chromium utifrån ovanstående...
Jag har jobbat lite på min simultanförmåga och kört flera webbläsare igång samtidigt på datorn med radion igång och när chrome-streamen hänger sig och loggar ett fel så fortsätter ie och "chrome med ie ua" snällt. Dvs. om/när något stör trafiken/nätverket på dator så påverkar det inte fallback-spelaren. Det säger nog inte så mycket mer än att vi har lyckats med någon form av avsmalning.
Ang:
Android (sony xperia) Chrome - Uppspelningen fungerar
Får du HLS-spelaren med backa-knapp (som i Chrome på Win) eller fallback-spelaren (som i IE på Win)? Med Chrome borde det vara den vanliga HLS-spelaren, eftersom Chrome på Android länge har haft stöd för den tekniken.
Nr 2 - jag får den vanliga spelaren. Jag ska testa detta ännu mer och se om problemet verkligen inte uppstår där. Det skulle vara skönt att kunna ringa in att det är något exklusivt för datorn. Det kan kanske påverkar att chrome på android har annat HLS stöd, då blir det svårare att bråka med.
Jag ska börja stänga av saker på min dator/testa på en dator som inte har antivirus och tex. Teams. Om det är något i windows så borde det ju vara ett program som är relativt vanligt, eller som fungerar likadant överallt. Teams känns som en sådan bov, det finns ju på mac också men jag skulle gissa på att det är mycket mindre frekvent.
En felkälla kan ju vara att jag nästan alltid kör nätverk via Wifi eller via en docka till datorn. Teoretiskt sett kanske det fungerar bättre med ethernet, om HLS/spelaren är väldigt känslig för sånt. Jag tror inte att detta ska vara ett problem, dockan och ethernet borde vara exakt samma, men jag har det i åtanke.
Jag tror som du inte att problemet finns i tillägg/plugins i chrome för jag har stängt av allt sånt och det fungerade inte i Edge. Annars hade jag misstänkt att adblockers och dyl. kan störa.
Ps. Trevlig helg! 😀
Du har fel. Att lyssna direkt på en kanal via webbläsaren i datorn är mycket vanligt, inte minst under kontorstid. Många lyssnare har den på dygnet runt, i princip. Eller på hela dagen, när de är borta (som "sällskap" åt ett husdjur eller för att potentiella inbrottstjuvar ska tro att de är hemma).
Jag har inte koll på siffrorna, men gissar att ditt sätt att lyssna är minst 100 gånger vanligare än Sons.
Andelen som använder IE bland våra besökare, är nog ungefär som genomsnitts-surfaren, det vill säga högst marginell:
Desktop Browser Market Share Sweden (Obs, enbart desktop)
Spelare på Android
Bra, då vet vi att skillnaden inte beror på "andra spelaren".
Tester
Jag ska börja stänga av saker på min dator/testa på en dator som inte har antivirus och tex. Teams.
Tack snälla! I och med att vi inte kan återskapa felet, är din hjälp enormt värdefull!
Chromecast-fel med likheter
Vi undersöker även ett fel som drabbar Chromecast från apparna för Android och Iphone (uppträder möjligen enbart på Ios 14).
Det finns flera likheter med "ditt fel" och jag har misstänkt att det finns en gemensam orsak (det vi kan kalla Sveriges Radio-faktorn). Bland annat:
- uppkom ungefär samtidigt
- efterhandslyssning påverkas inte alls
- oregelbunden frekvens
Vi har betydligt större antal felrapporter kring detta fel, trots att andelen lyssnare som använder Chromecast är liten jämfört med andelen som använder webbläsaren som en FM-radio. Och det har gått att reproducera.Kanalerna olika drabbade
Felet är olika frekvent på olika kanaler, något vi förstod först igår kväll och som vi försöker kartlägga. P3 är en drabbad kanal, även om P1 tycks ha störst problem (eller är en större kanal bland de lyssnare som castar/felanmäler hit?).
P2 har däremot inga avbrott alls! Och då blir min fråga ....
... får du detta fel på P2?
Vi har två P2-kanaler. Testa den som heter P2 på webben (som vi vet slipper avbrott på Chromecast), inte den som heter P2 Språk och Musik (där vi undersöker hur det fungerar).
Om P2 inte får några avbrott, så testa fler kanaler:
https://sverigesradio.se/kanaler
Jag har en teori om vilka kanaler som drabbas och inte, men den håller jag tyst om för att inte mina förväntningar ska påverka ditt test.
Jag tycker att vi har kommit en bra bit på vägen redan. Tack för hjälpen så här långt!
Kanalerna olika drabbade
Nu börjar det bli roligt! Jag instämmer/ser samma sak.
P1 - värst.
P3 - nästan lika illa men bättre.
P2 - inga problem!
P4 - hänger sig också men jag har testat väldigt lite.
Jag testar fler kanaler under eftermiddagen.
Tester av med olika program/datorer
Kanalerna hänger sig inte heller samtidigt när jag har flera igång samtidigt på samma dator, så vad det är som stör fortsätter va svårt att hitta något mönster i. Utöver kanalerna och webbläsarna då.
Jag tyckte ett tag att problemet påverkades av aktivitet i teams, dvs mkt aktivitet = radion hänger sig oftare. Det skulle ju kunna kopplas till varför det fungerar bättre på kvällar och helger. Men jag lyckas inte riktigt bevisa tesen/provocera fram en högre frekvens av fel. Och utan teams igång/installerat uppstår problemen fortfarande.
Jag har testat på datorer med och utan Office, Teams och Antivirus men lyckas inte se något tydligt mönster i att det blir bättre/sämre
Det kan såklart vara ett problem/bidragande orsak i sig att jag har testat med flera kanaler igång samtidigt.
Jag har försökt provocera fram felet genom att växla nätverk och härja med VPN osv men lyckas inte riktigt på så sätt heller. Det skulle vara fint att kunna peta på något och se att det ökar frekvensen.
Övrigt
Jag tyckte ett tag att det såg ut som att strömmen hängde sig i samband med google analytics skicken men det tror jag var fel. Det vara nog bara så att de råkade sammanfalla.
När spelaren hänger sig så blir ligger ju fortfarande play-knappen kvar som paus-symbol. Om jag då klickar på den två gånger så att strömmen hoppar igång så kommer hängningar inte att generera ett error.
Om jag däremot laddar om sidan (f5) så kommer nästa hängning bli ett error.
Det kanske inte har så mycket med problemet att göra men lär ju påverka mängden data ni får på "krascher".
En annan sak jag noterade som kanske kan hjälpa med isolering är detta; jag tror jag beskrivit att buffringen/spelarens tidslinje fortsätter efter att ljudet hänger sig. Jag ser ju att även om ljudet slutar hämtas så fortsätter browsern att hämta(skicka) "audiometadata" anropen korrekt så den delen av applikationen tuggar på opåverkat.
Är det samma kanal, som hänger sig i den ena webbläsaren men inte i den andra (båda i den nya varianten av spelare)?
Jag har försökt räkna ut ett sätt att testa att spela upp HLS-ljudströmmarna med en annan tjänst än vår sajt, för att se om det är något i vår spelare (skript-problem t ex) eller i själva ljudströmmen som är den där "Sveriges Radio-faktorn".
Den ljudströmmen används dock inte av någon Windows-tjänst.och går ite att spela upp i externa spelare, däremot nvänds den i våra mobliappar för Android och Iphone och i apparna för Sonos och Apple-tv. Det enda sätt jag kommer på är att använda vår app Sveriges Radio Play för Android.
Där finns det två olika varianter. I den ena (enklare tror jag) är det mobilen du kör appen på och egentligen bara speglar mobilen. Det bör ge den information jag är nyfiken på:
Använda appar från en Android-enhet på datorn
Om felet märks när Android-appen speglas och webbspelaren inte är involverad, så är det HLS-strömmen och hur den (inte) funkar ihop med din dator som är det centrala.
Om du däremot kan spela upp P3 utan problem den vägen, så är det inte uppspelningen av ljudströmmen som ger felet. Och då kan det bli intressant att testa en annan metod: Att "simulera att datorn är en Android-enhet". Jag vet att det funnits någon lyssnare som lyssnat så, och det fungerade - men det är något år sedan. Vad som är bästa sättet för en sån manöver är alltså inget jag vet något om, men jag kan höra med Android-utvecklarna om det blir aktuellt. Nästa vecka, för nu är det helg!
Trevlig sådan.
Jag har bara testat detta med olika kanaler tidigare. Dvs.
Fönster 1 = p1, Fönster 2 = p2 osv osv.
Nu har jag testat med samma kanal i olika webbläsare och de hänger sig oberoende av varandra också. Dvs.
Fönster 1 = p1, Fönster 2 = p1 osv osv.
Så oavsett vilken kanal (av de problematiska) det är så hänger sig olika chrome-fönsters spelare "hipp som happ".
Jag har meckat med speglingen/windows 10-verktyget och det fungerar inte med den smartpone jag har tillgång till. Jag har android studio installerat så det är inte superbökigt för mig att emulera en telefon därigenom om det duger för test. Jag gör ett sånt test och återkommer.
Gör det! Jag kollar med Android-teamet om det är något speciellt att tänka på.
Tack. Att det inte är "synkroniserade" avbrott i en och samma kanal, tolkar jag försiktigtvis som att det egentligen inte kommer ut "ett tydligt fel som får webbläsaren att krokna" utan att det uppstår för att någonting lägger sig på kö och till slut inte kan läsas in.
Tips från coachen: Ha ljudet avstängt på alla utom en! 🔇
Har du möjlighet att se om det finns något misstänkt i hur RAM och CPU ser ut medan du lyssnar i Edge/Chrome på en kanal åt gången, alltså "den normala lyssning" du ägnade dig åt innan jag lurade dig åt att spela upp en massa radio samtidigt i olika flikar?
Både för webbläsaren som spelar upp, alltså om vår webbspelare förbrukar orimliga resurser, och för andra processer (t ex om något säkerhetsprogram får CPU-spikar när informationen om vilket program som sänds läses in). Och om det syns någon skillnad mellan exempelvis P3 och P2 ...?
Om det inte vore så trist med själva avbrotten, så skulle jag tycka att felsökningen här är ovanligt intressant ...
Galet, men otroligt värdefullt, i och med att vi inte kan återskapa avbrotten själva!
Jag instämmer i att det är lite galet, och tyvärr gav det inget vidare effekt. Det Fungerade problemfritt under förmiddagen att lyssna genom en emulerad telefon. Inte så stort tidsspann testat dock.
Jag får problemen även på en dator som står och inte gör någonting annat men kanske ska kika på om det handlar om att datorns RAM/CPU tar slut.
Jag tog ett kliv tillbaka och började kika på vad det är som händer i webbläsaren när spelaren hänger sig. För att ev. kunna förstå vad i min miljö som påverkar detta - och som i sin tur gör att det inte går att återskapa hos er eller på de mindre kanalerna.
1) HLS-strömmen hämtar ju kontinuerligt sitt manifest. Dvs. ".m3u8"-filen, chrome gör det ungefär var 5e sekund.
2) När spelaren hänger sig och får ett manifest parse error så är den filen alltid blank - men den hämtas fint med 200 som statuskod. Filen är inte tom eller null utan innehåller/parseas till en tom sträng.
3) Felhanteringen i HLS-javascriptet i spelaren kontrollerar att filens innehåll är en sträng och att statuskoden är 200. Sedan söker den efter manifestegenskaper vilket den inte hittar i en tom sträng. -> pang spelaren hänger sig med manifest parse error.
Ibland får chrome alltså en tom fil av urlen. Tex. https://live-cdn.sr.se/pool1/p3/p3.isml/p3-audio=192000.m3u8. Och ibland får den en fil som innehåller listan på filer som utgör streamen. Detta är i princip omöjligt att testa manuellt för varje gång man besöker urlen får man ett korrekt manifest. Men såhär blir det för chrome ibland:
200 ok - blank
200 ok - manifest
Jag kan för lite om HLS och er värld men det lär ju påverka om manifestfilen tex. är statisk eller genereras vid varje anrop.
Annat som kanske innehåller ledtrådar:
* Har ni i er miljö testat i utvecklingsmiljöer där ni tex. alltid får en ny genereradmanifest-fil eller något sådant?
* Har ni annan config är vad lyssnaren får i chrome? Jag ser att spelaren har config parametrar för retry/timeout gränser som kanske skiljer sig?
* Går ni mot en annan "pool" eller server som inte är samma som min webbläsare går mot?
* Kör android appen någon annan felhantering som inte godtar den tomma strängen som ett "ok" manifest?
* Vad skiljer de "stora kanalernas" p1, p2, p3, p4 manifestfil/hämtning mot de mindre där det inte uppstår. Det kanske uppstår där men för sällan för att märkas?
* Kan nätverks-hastigheten påverka?
* Kan chrome eller er server ha någon cache-magi inbyggd som påverkar?
* Vad skulle i mina datorer kunna påverka att jag ibland får en blank fil som svar?
...
...
Jag tycker att följande trådar diskuterar ungefär det jag ser, men de är inte så aktuella vad gäller datum:
https://github.com/videojs/videojs-contrib-hls/issues/952
https://github.com/video-dev/hls.js/issues/615
Att vi i samband med bytet av CDN i höstas fick fler tomma m3u8-filer än vad vi hade tidigare, har vi konstaterat. Det är det problemet jag haft i åtanke när jag skrev:
De tjänster som använder HLS-strömmarna är:
allvarliga problem, men förhållandevis få drabbade, kanal spelar in
inget påtagligt problem
inget påtagligt problem
stora problem som drabbar alla, löst med work around (trafiken går inte över vårt CDN), såg då ingen koppling kring att kanalerna drabbades olika - men det kan finnas
stora problem som drabbar alla, kanal spelar in
för få användare för att ge mig en bild av eventuella problem
Vilken faktor som styr att vissa användare drabbas medan andra inte gör det vet vi inte.
Om det var så pass stort tidsspann att du hade fått felet vid vanlig webblyssning, så ger det en fingervisning om att felet inte enbart beror på de tomma strängarna, utan även på ett JS som smäller när detta sker, och att Android-appen har ett annat sätt att hantera detta.
Men varför blir det så hos dig, och inte hos alla?
Varför hos dig men inte hos alla?
Att jag tvärsäkert säger att felet inte uppstår hos så många har inte så mycket med våra tester att göra som att jag arbetat med support av vår webb i 20 år och vet hur inflödet av felanmälningar ser ut när ett fel drabbar en stor del av lyssnarna. De tester vi gjort har skett på privata datorer med olika webbläsare och utanför SR-nätverket. "Normala lyssningsförhållanden". Jag har kollat vilka kanaler mina kolleger har testat (så att inte alla var P2), och det var "problemkanaler".
Är det färre tomma strängar i P2 än i P1, eller är den delen lika, men något annat olika?
Jag måste bolla detta med fler kolleger. Än så länge är det framför allt utvecklarna av sajten som engagerats, och deras roll är fortfarande viktig för att se om vi kan hantera de tomma strängarna bättre - men grundfelet ligger i att vi ens har den här typen av tomma strängar.
Nu har vi flera konkreta uppslag att nysta från.
Tack.
Hej igen!
Vilka kanaler har du testat hittills? Du hittar alla här:
https://sverigesradio.se/kanaler
Jag har, efter kontakt med en kollega som felsöker, en ny hypotes! Enligt den teorin ska de kanaler jag har markerat med gult ge avbrott, de övriga ska slippa det.
P3 Din Gata och P6 är jag dock lite osäker på. Jag är dessutom inte helt på det klara över om P2 Språk och Musik verkligen får avbrotten.
Den gemensamma nämnaren jag tänker mig, är om de sänds i FM eller inte, och att det är någon skillnad i distributionskedjan mellan "ren webbkanal" (fungerar) och "FM-kanal på webben" (får avbrott).
Den P2-kanal som inte är drabbad sänds visserligen i FM, lokalt i Sthlm, men jag tror att den "rent tekniskt" fungerar mer likt P4 Plus och dylika webbkanaler.
Finns det något i dina tester som talar emot denna hypotes?
Det är just castingen jag använder för att kartlägga felet, både själv och med hjälp av lyssnare.
De kolleger som arbetar med tekniken mer "hands on", undersöker "tomma M3U8-filer" på olika sofistikerade sätt. Felsökningen står och faller alltså inte med att du har möjlighet att testa detta. Din hjälp är värdefull och välkommen, och har snabbat på felsökningen. Men nu när du bidragit till att vi ser var vi ska felsöka, så kommer vi att ringa in felet ändå.
Jag har dock nu under förra och denna vecka in haft några problem alls, så om ni har ändrat något så kan jag se att ni petar på rätt ställe. Annars är det bara ytterligare en observation som ni kanske kan koppla till något i er ände. Jag kan inte se att något har ändrats i min ände.
P2 språk och musik har jag inte testat (vad jag minns), och just nu uppstår felen inte så det är svårt att testa. Jag har ingen möjlighet att testa med chromecast tyvärr.
Vi ska förmodligen inte få cred för det, eftersom jag inte har sett något som vi skruvat på och, viktigare, felen fortsätter i exempelvis Chromecast.
Ni var, som jag skrev, få som rapporterat in felet i Windows, och andelen som rapporterar in när fel upphör är förstås alltid ännu lägre. Svesse är dock en annan drabbad lyssnare. Han skrev den 8 januari:Jag har, som du vet, haft en teori om att ni som drabbades av felet har någon gemensam nämnare (exempelvis ett säkerhetsprogram). Med den teorin passar det in att felet upphörde samtidigt hos dig och Svesse i samband med någon automatisk uppdatering. Era miljöer är nu "normal-toleranta" och felet i våra HLS-strömmar ger inte avbrott. Men det finns kvar. Och det måste lösas!
Kommer du på vilken faktor hos dig som kan ha bidragit, så är det förstås intressant.
Jag har samma problem. Stänger av streamen på p3 efter en stund i mobilen. Testat allt på telefonen men hittar inget samband mer än att det rör p3. Spotify funkar tx.
Se om du kan lyssna genom direktlänkarna på denna sida, som använder en annan teknik än ljudströmmarna på hemsidan och i appen:
https://sverigesradio.se/artikel/3771842
De felrapporter som vi fått hittills från dig och andra lyssnare är värdefulla, och jag återkommer med information (och säkert med frågor) så snart jag hinner!
Felet ska nu vara löst. Om det kvarstår hos dig, Johan, så hojta till!
Det har funkat kanon under eftermiddagen!
Härligt jobbat! Tack!
//Johan