Pauser/"dropouts" i P4 Plus-strömmar (RadioTray)
Hej!
Jag lyssnar ofta på P4 Plus via 96 kbps AAC-strömmen https://sverigesradio.se/topsy/direkt/4951-aac.m3u i mediespelaren VLC (på dator kabelansluten till en högst kapabel Gigabitrouter) över en 100/100 Mbit fiberanslutning, utan någon som helst bandbreddskrävande aktivitet igång samtidigt.
Med ojämna mellanrum pausar (någon gång verkar det dock handla om "dropouts") strömmen under ett antal sekunder (upp till ca. 5-6 sekunder). Samma fenomen uppträder med 128 kbps mp3-strömmen och även med AAC- och mp3-strömmarna i ännu lägre kbps. "Vanliga" P4 fungerar helt perfekt.
Vet inte vad jag skulle kunna förändra "i min ände" att få P4 Plus att fungera som avsett...
Med vänlig hälsning
Mikael
Jag lyssnar ofta på P4 Plus via 96 kbps AAC-strömmen https://sverigesradio.se/topsy/direkt/4951-aac.m3u i mediespelaren VLC (på dator kabelansluten till en högst kapabel Gigabitrouter) över en 100/100 Mbit fiberanslutning, utan någon som helst bandbreddskrävande aktivitet igång samtidigt.
Med ojämna mellanrum pausar (någon gång verkar det dock handla om "dropouts") strömmen under ett antal sekunder (upp till ca. 5-6 sekunder). Samma fenomen uppträder med 128 kbps mp3-strömmen och även med AAC- och mp3-strömmarna i ännu lägre kbps. "Vanliga" P4 fungerar helt perfekt.
Vet inte vad jag skulle kunna förändra "i min ände" att få P4 Plus att fungera som avsett...
Med vänlig hälsning
Mikael
Följ inlägget
2
följare
Felet ligger på vår sida och därmed har du gjort det du kan - kontaktat supporten!
Felet har troligen att göra med ett problem som teknikerna identifierade igår (relaterat till en del av "distributionskedjan" som kallas cdn). Jag vet inte om detta är löst, och tar reda på det, förstås!
Troligen har det ingen betydelse, men i hastigheten råkade jag skriva något som inte längre är korrekt. Ber om ursäkt för det. Det är inte VLC jag använder, utan ett program som heter Radiotray-ng. Jag ska testa P4 Plus med andra mediespelare och i webbläsaren för att se om det blir någon skillnad.
Vi tar gärna emot din hjälp att förstå problemet, för ni är några lyssnare som har liknande problem och det CDN-problem jag hade i tankarna borde inte påverka dig som lyssnar med direktlänkar, så jag förmodar att felet kvarstår!
Hur länge har det pågått?
P4 Plus är, tillsammans med P2 och Radioapans knattekanal pilotkanaler där vi, sedan i september för P4 Plus del, testar en nya streaming-plattform. Kan problemet ha pågått så länge, eller är det något som har uppstått först den senare veckan?
Samma ström, men utan M3U
Testa gärna om denna länk fungerar bättre:
https://sverigesradio.se/topsy/direkt/4951.aac
Det är också AAC i 96 kbps, men utan att "förpackas" i en spellista. Jag är nyfiken på om det gör någon skillnad.
Tack på förhand för vidare hjälp att förstå problemet!
Körde sedan m3u i VLC under ett par timmar. Noterade ingen paus, men å andra sidan kunde jag inte lyssna oavbrutet, och det kan ibland vara väldigt långt mellan pauserna. Fortsätter med VLC i morgon eftermiddag.
Vi uppskattar verkligen din hjälp att ringa in detta problem. Finns det någon inställning i Radiotray där du kan styra hur stor bufferten är i själva spelaren? Testa i så fall om en ökad buffert ger färre avbrott! Jag misstänker nämligen att orsaken till problemet är att vår nya streaming i P4 Plus har "lägre latency" (kortare fördröjning, men samtidigt mindre buffert) än övrig streaming, alltså den vi har på "vanliga P4", där du inte får några problem.
Om du inte kan reglera bufferten i Radiotray, så kan du testa alternativa länkar med en lite större buffert.
Vi har två olika servrar som du slumpas till med "de vanliga länkarna". Streaming-servrarna ska vara konfigurerade på samma sätt, men om problemet har koppling till just den ena delen av vår miljö vill vi förstås ringa in det! Här är direktlänkar till P4 Plus med lite mer buffert, AAC 96 kbps, på respektive server:
- https://edge1.sr.se/p4plus-aac-96?latency=high
- https://edge2.sr.se/p4plus-aac-96?latency=high
Hoppas att de länkarna ger dig möjlighet att lyssna utan avbrott! Berätta hur det går.Det är väldigt trist att du har de här problemen, men jag är tacksam över att du berättat för oss om det och vill att du ska veta att den felsökning som du hjälper oss med förhoppningsvis kommer fler lyssnare tillgodo!
Hacken i det öppna och flexibla Radiotray påminner om problem som drabbar ett fåtal internetradio-apparater. Dessa apparater är en mardröm att felsöka för att det är svårt för lyssnare att själva lägga till länkar och för att den tjänst apparaterna hämtar länkar från inte visar tydligt vilken av våra ljudströmmar det är som ligger inlagd i radiotjänsten eller hur länken ser ut.
Om länkarna med lite större buffert (parametern "?latency=high") ger avbrottsfri lyssning i Radiotray, finns det dock skäl att anta att större buffert även kan behövas i dessa manicker, vilket vi då kan försöka lösa.
Så tack på förhand för all hjälp att förstå detta problem!
Trevlig helg
Det blir ännu fler och längre uppspelningspauser om Radiotray-NG:s buffert ökas från standardinställningen (buffer-duration=2 (sekunder), motsv. 640000 byte buffert). Via debugloggningen såg jag att detta orsakas av upprepade "buffering timeout, restarting stream...".
Med standardinställningen kommer "started buffering" i samband med pauserna, ingen timeout.
Om bufferten minskas till den minsta som accepteras (buffer-duration=1, motsv. 320000 byte) så elimineras pauserna helt. Jag (och debugloggen, som fått "lyssna" när jag inte kunnat :-)) har i alla fall med den inställningen inte noterat någon paus alls i https://sverigesradio.se/topsy/direkt/4951-aac.m3u. "1 sekund", dvs. 320000 byte tycks alltså vara mer eller mindre optimalt för min situation, med Radiotray-NG och underliggande gstreamer.
Jag kan inte C++, men min tolkning av källkoden är att Radiotray-NG helt enkelt kräver att bufferten är 100% fylld för att spela upp, och pausar uppspelningen när så inte är fallet. Pauserna innebär ju hur som helst att strömmen med ojämna mellanrum inte klarar att hålla bufferten (tillräckligt) full.
Ang. VLC har jag hittills inte kunnat notera någon paus med https://sverigesradio.se/topsy/direkt/4951-aac.m3u. VLC:s standardbuffert är f.ö. "network-caching=1000" (ms), vad det nu kan motsvara i byte... (Har inte orkat kolla i källkoden, men cachen är kanske adaptiv, så att storleken varierar beroende på video- eller audioströmmens hastighet?)
Kan till sist även meddela att ingen av de båda "höglatensströmmarna" under den tid jag testat pausade med Radiotray-NG:s standardbuffert. Ökar man buffertstorleken blir det dock pauser även med dem.
Hoppas att detta kan vara till någon hjälp.
För kanske tio år sedan felsökte jag en open source-spelare som fick problem vid låg bitrate men fungerade bättre vid hög. Problemet då berodde på att bufferten var satt till en viss datamängd snarare än till en viss tidsrymd, och att det, vid låg bitrate, blev time out innan bufferten var "fulltankad". Bufferten behövde vara full för att spelaren skulle fungera.
Jag minns inte vilken spelare det var, men din beskrivning får mig att misstänka att det var RadioTray.
Testa gärna om den högsta kvaliteten ger färre avbrott hos dig än den lägsta:
- https://live1.sr.se/p4plus-aac-320 (320 kbps) - bör kunna öka bufferten utan problem
- https://live1.sr.se/p4plus-aac-32 (32 kbps) - bör få problem även vid lägsta buffert
1 respektive 2 kan alltså inte vara sekunder, om jag räknar rätt. Jag är inte van att räkna i bytes, men med hjälp av en enhetsomvandlare får jag det till att den lägsta möjliga bufferten i RadioTray, på 320.000 byte, motsvarar 2560 kilobit. Med vår nya "premiumström" på 320 kbps, blir detta 8 sekunders buffert och vid 128 kbps är det 20 sekunder!Vad än "1" står för, så är det en bra inställning för dig, vilket är det centrala. Du fick problem när vi minskade "latency", men för RadioTray är den bästa lösningen troligen inte att öka bufferten i strömmen, utan att minska kravet på buffert i själva spelaren.
Även jag insåg förstås att vad som i dokumentation angavs vara "sekunder" ("buffer-duration: number of seconds to buffer") inte nödvändigtvis var det "rakt av", utan i praktiken kanske bara ett sätt att kontrollera buffertstorleken, som är hårdkodad.
Är som sagt inte bra på C++, men jag hittade några suspekta egendomligheter i koden. Men... sak samma, jag är nöjd med att ha hittat en inställning som gör att jag kan lyssna utan pauser.
Tack för hjälpen, Annika!
Jag lyssnar på P4+ och använder Linux med kommandot "cvlc https://sverigesradio.se/topsy/direkt/4951-hi-mp3.m3u" och upplever också avbrottsbroblem.
Ibland några timmars avbrott men ibland mer än ett dygn...!
/Bengt T
Avbrott på timmar eller dygn är ett helt annat problem än det buffringsmysterium som Mikael och jag har kartlagt ovan.
Stream Exceeded Listener Capacity
Förra helgen var det flera lyssnare som inte kom åt P4 Plus på grund av en konfigurationsmiss från vår sida som gjorde så att licensregistreringen slutade fungera och att antalet tillåtna samtida lyssnare därför slog i taket. Teknikerna fixade det förra söndagen, den 3 december.
Detta fel skulle kunna ligga bakom en del av problemet, men eftersom du skriver hit över en vecka senare, så misstänker jag att du har stött på problem även därefter. Det stämmer i så fall överens med det jag sett hos en del lyssnare med internetradio-apparater, vilka är väldigt svåra att felsöka eftersom varken lyssnaren eller vi på Sveriges Radio kan se vilken ljudlänk som används eller vad som är fel. Vi har därför tyvärr inte fått grepp om vad som gått snett hos dessa lyssnare.
Fel-logg från cvlc?
Ur det perspektivet är det väldigt trevligt med fristående spelarprogram i allmänhet och open source i synnerhet! Jag har dock inte hört talas om cvlc tidigare, men ser att det är "vlc utan grafisk presentation". Låter som ett smidigt sätt att lyssna!
Jag förmodar att du, om en kanal inte går att starta eller plötsligt tvärdör, får något felmeddelande i kommandotolken eller i en fel-logg. Om det stämmer, är jag förstås nyfiken på vad som blivit fel och om möjligt att kunna se när det har blivit problem!
Felet från förra helgen har hos en annan lyssnare (Henrik här med okänd plattform) gett 403 Forbidden: Stream Exceeded Listener Capacity. Enligt honom har samma felmeddelande synts även dessförinnan, vilket jag ännu inte har hunnit kartlägga.
Förändringar i format och kvaliteter
Jag passar på att berätta att den MP3-länk du nu använt framöver kommer att "chocksänkas" i kvalitet från 192 till 96 kbps. Vi ska nämligen renodla vilka format och kvaliteter vi erbjuder, och endast erbjuda en MP3-länk. De tre MP3-kvaliteter vi har idag, kommer alla att länkas om till 96 kbps.
För er med Linux är det förhoppningsvis intressant att vi i samma veva kommer att erbjuda en Opus-länk, vilket vi fått in önskemål om här:
Använd gärna Opus, ett bra ljudformat
Vi har ännu inte beslutat vilken bitrate Opus-strömmen ska ha, så passa gärna på att berätta hur ni ser på saken! Jag har förordat 96 kbps, samma som för MP3. Opus komprimerar ljudet på ett bättre vis än MP3, och en Opus-ström i 96 kbps är fullt njutbar trots modest kvalitet. Vi är självfallet lyhörda för vad ni lyssnare tycker!
Även en Flac-ström kommer. Den är i mycket hög kvalitet (variabel bitrate som pendlar mellan 600 och 1000 kbps). Det är mer än vad de flesta lyssnare - eller deras anläggningar! - har nytta av, och mer tänkt för "audiofil-anläggningar".
Vårt huvudformat förblir AAC, som fungerar på Linux med rätt codec. Där kommer vi att erbjuda flera olika kvaliteter, från 32 till 320 kbps.
Min "steamer-spelare" är en fristånde Raspbery Pi utan skärm. Har därför ej möjlighet att läsa av ev. felmeddelande, som skulle kunna upplysa om vad som strular när så är fallet.
Någon cvlv/vlc-log har jag ej aktiverad och kan tyvärr ej meddela något log-resultat heller.
Det jag kan "erbjuda", om/när det inträffar igen, är att ansluta mig till "streamer-spelaren" från annan dator, via ssh..., och försöka avläsa ev. felmeddelnden samt aktivera och avläsa vlc/cvlc-log.
Betr. reduktion till 96 kbps samt att övergå till "ogg" är det ok för min del.
/Bengt T
De flesta som lyssnar med den här typen av länkar gör det i internetradio-manicker där länkarna hämtas via en aggregator. Dels är det oftast otydligt vilken länk som används och om det finns felmeddelanden så ger de sällan någon egentlig hjälp. Dessutom är många internetradio-lyssnare ointresserade av IT och har sökt sig till ett sätt att lyssna där det räcker med att trycka på en fysisk knapp för att lyssna på P4 Plus.
Jag må vara lite fördomsfull här, men jag utgår från att lyssnare med en Raspbery Pi generellt är mer vana att ringa in webbrelaterade problem 😉 Och om ett problem märks i cvlc med våra vanliga länkar så kan det ju ligga på vår sida och även drabba de "aggregator-baserade" enheterna! Din felsökning kommer därmed även de lyssnare som inte kan felsöka själva tillgodo.
Så ... Om du tar dig tid att hjälpa oss att ringa in problem, så tackar jag på förhand. Tack även för återkoppling om våra format-planer!
Återkommer när/om strulet återkommer.
/Bengt T
Det tog lite längre tid än vad jag trodde, men här är de:
- https://live1.sr.se/p2musik-opus
- https://live1.sr.se/p4plus-opus
Båda länkarna fungerar även med http i början, om ni har det behovet. Än så länge är det endast dessa kanaler vi har i Opus.Vi kan, ifall så önskas, även skapa en Opus-ström för Radioapans knattekanal. Säg till om ni vill ha en sådan. De övriga kanalerna kan vi inte erbjuda i Opus ännu, utan först när vi övergått till den nya streaming-plattformen, vilket förmodligen sker om ett par månader.
Testade Opus-länkarna ovan men inget ljud kom fram...
Hursomhelst, länkarna jag använder f. n. har duger för mig t. v.
/Bengt T