Kommentaren du söker har flyttats till en ny diskussion, eller är borttagen.

Squeezebox Radio: Poddfiler stannar efter en viss tid

Hej!
Dax igen för stoppad podd. Har pågått någon vecka nu. Stoppar ibland redan efter 5 minuter.
Kör Squeezebox Radio precis som för ett år sedan med samma problem.
Ni måste ha gjort någon ändring som tog bort "fixen" för squeezebox.
Jag har fiber och mycket stabil uppkoppling.
Snälla kolla upp vad som hänt och åtgärda. Jag lyssnar nästan enbart på radio och podd genom Squeezebox. Har varit perfekt innan.

Johan Rapportera olämpligt innehåll

Kommentarer

  • Hej Johan:!
    Jag ser att du i den ursprungliga tråden skriver om att du använder länkar till senaste poddar. Är det för dessa felet gäller eller är det problem även med kanaler? Har du gjort några andra förändringar eller uppdateringar?

    supporter
  • Bra problem med poddsändningar som jag prenumererar på med radion.
    Kan sedan välja vilket avsnitt jag vill lyssna på.
    Radiosändningar stoppar aldrig. Internet 250/100. Svt-play funkar perfekt mm.

    Johan
  • Poddarna är alltså nedladdade till Sqeezeboxen? Så det handlar inte om strömning från SR-servrarna? Mysiskt fel. Inga fler felanmälningar verkar ha kommit in.

    supporter
  • Nej de är inte nedladdade, bara förteckningen över program.

    Johan
  • Jag tolkade att du kan välja avsnitt som avsnitt av samma program. Ok... Eftersom strömmen startar bör detta fel i alla fall inte ha med fixen från 2015 att göra, eller var det så att det fungerade på exakt samma sätt innan den fixen?

    supporter
  • Då stoppade poddsändning år efter 10-15 minuter.
    Ungefär som nu.
    Något har ändrats. Kan vara för någon månad sen då jag inte lyssnat på podd så ofta senaste tiden.

    Johan
  • OK! Har du testat att spela samma avsnitt på datorn med VLC media player? Fungerar det då normalt?

    supporter
  • Jag har spelat samma avsnitt i mobilen mecd SR app.
    Inga problem.

    Johan
  • Då är felanmälan komplett. smile
    Och i Radiotray fungerar det också.
    Vad säger Sveriges Radio?

    supporter
  • ...för felsökningens skull hade det visserligen varit bättre att inte använda appen. Det blir inte samma ljudlänk med appen och då kan det eventuellt även vara en annan server som är inblandad.

    supporter
  • I Radiotray stoppar strömmen efter ca 20 minuter i ett timmes långt program, när jag testar igen.

    supporter
  • Hej!

    Jag bröt ut denna felsökning till en ny tråd. (Tidigare låg den här.) Eftersom jag minns vad det var för fel och för fix, kommer jag att ställa en del frågor för att ringa in om det verkligen är samma fel eller ett snarlikt fel. Jag lutar åt det senare, tyvärr, eftersom det innebär att vi åter kommer att behöva ägna tid åt felsökning.

    En viktig fråga har Supporter redan ställt:
    Var det så att det fungerade på exakt samma sätt innan den fixen?

    Jag vill specificera det ytterligare:
    Vid felet i fjol nådde ljudfilerna fram till en punkt när det bröts. Samma avsnitt bröts alltid vid samma punkt. När det var stopp gick det inte att komma vidare. Enheter med spellistor (vet inte om det gäller Sqeezebox radio, felet drabbade många enheter som strömmar poddfiler, snarare än att ladda hem dem) skuttade vidare till nästa fil i listan.

    Dessutom var det ett fel som uppstod på alla avsnitt av alla program (undantaget om programmen var så korta att felet inte hann uppstå) och det var inte exakt konstant i tid. Avsnitten bröts efter kanske 13-15 minuter på en enhet och 8-10 minuter på en annan, men inom det intervallet var det till hundra procent reproducerbart.

    Är det på samma vis nu? Uppstår detta på alla avsnitt utan undantag? Och går det inte att på något vis (play - paus - play, till exempel) återta lyssningen och komma förbi den kritiska punkten?

    Eventuella liknande fel idag
    Vi har ett par andra aktuella felanmälningar om avbrott i strömmade poddfiler på andra plattformar (Itunes och Podcaster) som möjligen kan ha samma orsak som det fel du beskriver, men ifall vi felsöker dessa som ett gemensamt problem eller som separata hänger lite samman med vad du svarar på mina frågor.

    Alltså:

    • Om du lyssnar på samma avsnitt vid två tillfällen, blir det då avbrott vid exakt samma punkt?
    • Uppstår detta på alla våra avsnitt (men inte på andra poddar), utan undantag?
    • Kan du på något vis ta dig förbi avbrottet och lyssna klart?

    Tack för att du rapporterade in detta och för den kartläggning ni redan gjort, som sparade in en del tid för oss och gör att jag sluppit ställa en massa frågor smile

    Annika Webbmaster
  • Tack för svaret!
    Jag har nu testat tre gånger med Kropp o själ, avsnitt Dansens kraft.
    Det stoppade vid olika tider varje gång. Mellan 10 till 24 minuter.
    Jag har haft samma problem med ett flertal SR-poddar senaste veckorna.
    Om jag lyssnar på annan podd (teknikpodden, har bara den också) så stannar det inte.
    Jag lyckas inte återstart fortsättningen. Bara starta om från början. Kan då snabbspola och börja lyssna 10 - 20 minuter igen.
    Mvh
    Johan

    Johan
  • Tack!

    För att vara säker på att jag har förstått detta rätt:

    Jag lyckas inte återstart fortsättningen. Bara starta om från början. Kan då snabbspola och börja lyssna 10 - 20 minuter igen.

    Kan du alltså spola förbi det gamla stoppet och höra klart avsnittet?

    Annika Webbmaster
  • Ja jag kan spola förbi stoppet. Tror också att jag kan börja spela lite innan stoppet och passera det när jag lyssnar.
    Verkar ju som om det mera hänförs till buffring o dylikt eftersom det stoppar vid olika punkter varje gång.

    Johan
  • Jag tror att det är något med vår teknik som skapar problem hos ett fåtal lyssnare, och att det troligen finns någon gemensam nämnare hos er som drabbas.

    En annan lyssnare med Squeezebox (som också tänkte att det var fjolårets problem som hade återuppstått) hörde av sig via e-post och skrev:
    Den senaste tiden, kanske sen ett par veckor, har liknande problem börjat dyka upp. Nu lyssnar jag på Lördagsintervjun och strömmningen avbryts ungefär varje 15 minuter.

    Victor, med Itunes på Windows 7, har haft problem med avbrott på våra - men inte andras - poddar sedan i somras ungefär:
    Poddar stängs av i iTunes

    Även om det felet är en annan plattform och har pågått längre, så skulle det kunna vara något med vår teknik ger problem med en viss typ av brandväggar till exempel. Då kan samma fel uppstå vid olika tillfällen hos besökare beroende på när man själv eller nätleverantören gjort olika uppgraderingar.

    Lurigt är det i alla fall!

    Hur knepigt är det att koppla upp din Logitech mot ett annat nätverk? Om det går någorlunda enkelt, så tycker jag att det vore intressant att se ifall uppkopplingen spelar roll.

    För att förtydliga: jag tror inte att det är något fel på uppkopplingens hastighet, 250/100 ska räcka för att spela upp en poddfil wink Däremot kan det finnas något med brandväggar och dylikt som påverkar, och att se om du kan återskapa felet över en annan uppkoppling vore intressant!

    Hur fungerar det annars med uppgraderingar av firmware för din Squeezebox? Kommer sådana automatiskt utan att du märker av det? Om inte, har du uppgraderat något i anslutning till att felet dök upp? Med tanke på att vi har fått in ytterligare felanmälan om just Squeezbox är det bra att veta om det kan finnas någon sådan sak att felsöka!

    Annika Webbmaster
  • PS:
    Frågan du postade i en annan tråd squeezebox-tråd, har jag raderat.

    Annika Webbmaster
  • Jo jag kan nog köra en Squeezebox via mobilens nätverk (Vimla), men inte precis nu...

    Verkar inte komma några firmware automatiskt. Har en spelare med en ngt äldre fw.
    Jag har inte ändrat något i systemet sen i somras utom att jag får internet via fiber. Allt annat är lika.

    Johan
  • Ok.

    När fick du fiber? Kan felet ha uppstått vid samma tid? Och vilken leverantör är det?

    Tack på förhand om du kan testa att dela nätverk från mobilen!

    Annika Webbmaster
  • Fick fiber en dryg månad sedan. Har fiber från Bjärekraft, Bredband2 som levererar Internet.
    Jag tror inte det var problem första veckorna med fiber.
    Ska testa att koppla upp en radio via mobilen i morgon.

    Johan
  • Kul med fiber! Det låter ju som om det ändå finns en viss möjlighet att felet har ett samband med detta, men dels att du troligen kunde lyssna utan problem till att börja med och dels att en annan lyssnare med Logitech har fått samma fel gör att det inte är det allra hetaste spåret.

    Återkom när du testat över mobilen! Och om vi har lite svårt att svara snabbt över julen, så ha tålamod med oss.

    Vi hörs!

    Annika Webbmaster
  • Hej, jag är den som kontaktat Annika via email och kan bekräfta att även jag har ett problem som liknar det som tas upp i tråden. Även hos mig är det inte lika regelbundet som förra gången, men det typiska är att podd-strömmar (aldrig live-sändningar) bryts efter 10-15 minuter. Dator/internet etc. har varit stabilt och jag har inte ändrat något på länge så jag har inga sådana kandidater till felkällor vad jag vet. Dock har jag uppdaterat operativsystem och liknande; vet inte om det är relevant. Kör media-servern på Mac med MacOS Sierra.

    Erik Frisk
  • Hej!

    Såg denna tråd av en slump och kan rapportera att jag har märkt samma fenomen med avbrott på min Squeezebox Radio när jag lyssnar på P1 Medierna podversionen sen en tid tillbaka.
    Hos mig är det inga ändringar alls vad gäller internetanslutning eller liknande från då det fungerade klockrent tills nu när jag får avbrott (fiber 100/100).

    Angående firmwareuppdateringar till Squeezebox så kommer det inte några fler då Logitech har lagt ned hela den produktserien. De fortsätter dock att supporta användningen.

    Jag har inte heller lyckats att återstarta spelningen när den stoppar. Däremot så går det bra att spola fram till stoppet och fortsätta lyssningen där.

    Clas
  • Jag har nu testat på olika sätt.
    Normalt kopplar jag till fjärrbibliotek på en Linux-server med Logitechs serverprogram.
    Om jag byter till uppkoppling mot mysqueezebox.com blir det samma sak.
    Både via WiFi eller kabel till router.

    Om jag kopplar upp via mobilen (Nexus 6P, Telenors nät) bryts det också på liknande sätt.
    Jag har testat med två olika Squeezebox radio, samma sak.

    Det tar olika lång tid innan det stoppar. Ibland bara ca 8 minuter, men ofta 15 eller mer.
    En gång gick hela programmet utan stopp.
    Jag har hela tiden testat med Godmorgon världen 20161218.
    Hälsningar Johan

    Johan
  • Erik, tack för att du kom hit! Och Clas, välkommen till forumet ... Det är inte roligt att ni är många med samma fel, men det underlättar onekligen felsökningen! (Det där kanske jag redan har skrivit? Det är hur som helst sant!)

    Tack för att ni rapporterat in hur detta fel yttrar sig. Med tre så likartade felrapporter på fyra olika Squeezebox-enheter, är det troligt att det är något hos oss som vållar problem i just Squeezbox.

    Om det är samma problem som dessutom drabbar t ex Itunes (se ovan), vågar jag inte uttala mig om, även om jag tycker att det borde ha kommit in fler felrapporter om dessa plattformar hade generella problem ...

    Johan, bra att du testade både med mysqueezebox och Logitech media service (en faktor jag inte tänkte på) och allt det andra testandet!

    Det vore väldigt bra att försöka ringa in när detta har uppträtt, och se ifall vi kan koppla detta till någon förändring som vi har gjort i streamingmiljön. Vi har gjort en hel del sådana under hösten, vilket har behövts men försvårar felsökningen ...

    Så, om ni kan ringa in när ni först drabbades av detta, eller när ni först insåg att det inte var en enstaka poddfil som hade problem, är det till stor hjälp!

    Johan skrev den 20 dec Har pågått någon vecka nu., Erik skrev den 17 december sen ett par veckor och Clas har fått felet på P1 Medierna podversionen sen en tid tillbaka. Johan, som fick fiber i november, kunde (troligen) lyssna utan problem över detta några veckor.

    Givet att felet är kopplat till en förändring på vår sida, är det troligen något vi har förändrat under andra halvan av november eller första halvan av december. (Har ni en annan uppfattning, så berätta! Det är ni som är experterna.) Vi kan dock ha gjort förändringar som inte gått ut till alla lyssnare samtidigt (vilket kan vara bra att fundera över eftersom Johans fel tycks ha visat sig något senare än hos er andra).

    Jag hör webbutvecklare och webbdrift vad de tror om detta!

    God jul!

    Annika Webbmaster
  • Jag får väl börja med att lägga in en stor brasklapp om att sånt här är väldigt svårt att komma ihåg.

    I alla fall, den första gången jag idag kan komma ihåg att jag upplevde det här problemet var under ett avsnitt av USA Valpodden. Sista veckan innan valet så la de ut ett avsnitt om dagen och på något av dem vill jag komma ihåg att det dog första gången. Valet var den 8:e november, så nån gång tidigt i november skulle bli min gissning.

    God Jul!

    Clas
  • Hej igen!

    Ytterligare en lyssnare, Anders, har rapporterat in problemet och jag har bett honom att kika in i denna tråd.

    sånt här är väldigt svårt att komma ihåg

    Oh ja! Jag vet ju knappt vad jag åt till lunch idag, så jag har all förståelse för att det är svårt!

    USA Valpodden är ändå ett tydligt riktmärke. Sedan kan det förstås ha förekommit andra fel med avbrott lokalt eller hos oss som grumlar bilden, så vi kommer nog inte att kunna ringa in detta helt exakt. Men att göra ett bra försök är ändå vettigt!

    Jag skickade en fråga till mina kolleger den 23 december och frågade lite allmänt om någon hade en teori om vad som kan ha förändrats som påverkar er, men många är jullediga och det är svårt att få ett bra svar.

    Jag påminde dem nyss om frågan och bad att de funderar med början av november som fokus.

    Är det någon av er som har stött på något avsnitt eller rent av någon hel programserie från oss som inte får denna typ av avbrott? Så att ni konsekvent får problemet med Medierna men aldrig med Släktband till exempel? Mitt intryck hittills är att det är ett generellt Sveriges Radio-problem, men jag inser att jag ju i alla fall behöver fråga, så att vi inte missar något viktigt!

    Annika Webbmaster
  • Hej.
    Nu har även jag hittat hit (tack Annika).
    Jag har samma symptom som tidigare nämnts i tråden, dvs:

    1. Strömmade kanaler är inga problem, det går att lyssna i timmar utan avbrott.
    2. Strömma podcastavsnitt leder oftast till avbrott efter 10+ minuter (jag lyssnar oftast på p1/p3 dokumentär och spanarna). Vi har kört Julkalendern hela december utan ett enda avbrott men jag gissar att avsnitten är rätt korta.
    3. Vid ett avbrott går det fint att starta om strömmen från början, spola fram och fortsätta lyssna (i ytterligare 10+ minuter).
    4. Jag lyssnar nästan uteslutande på sr's poddar så jag kan inte gå i god för om övriga poddar beter sig felfritt. Jag är ganska säker på att jag har haft avbrott även när jag lyssnat på 'Värvet' men inte 100.

    Vad gäller tidpunkten så är även jag mycket osäker (tyvärr). Jag upplever att detta har pågått sedan september/oktober men ta det med en stor nypa salt (jag har fram till idag utgått från att det har berott på tekniska problem på min sida).

    Tekniskt så ser min ände ut som följer:

    • En server (ubuntu 16.04 x64) kör Logitech Media Server Version: 7.9.0 - 1464986354

    Perl Version: 5.22.1 - x86_64-linux-gnu-thread-multi
    Database Version: DBD::SQLite 1.34_01 (sqlite 3.7.7.1)

    • 4 spelare
    • 1 Squeezebox Duet
    • 1 Squeezebox Radio
    • 2 Raspberry Pi med PiCorePlayer v3.02 (som emulerar en squeezebox mha Squeezelite)

    Servern sitter på ett internt virtuellt subnät (192.168.12.xx) och spelarna på ett annat (192.168.11.xx)

    • Alla spelarna är uppkopplade via WiFi till servern
    • En asus router som kör DD-WRT håller ordning på de virtuella näten och fungerar som brandvägg, dels mellan ...11.xx och ...12.xx och dels 'upströms'.
    • Ett kabelmodem från ComHem sitter mellan routern och väggen.
    • Från väggen och ut i stora världen är det ComHem's bredband via kabel-tv nätet.

    Jag hjälper gärna till att felsöka efter bästa förmåga, ev har jag möjlighet att slå på loggning på någon av mina Raspberry's, skall kolla upp det.

    Anders
  • Nu har jag försökt felsöka lite:

    • Jag installerade 'squeezelite' på en 'vanlig' ubuntu pc (kallad testbox nedan) så att jag kan fånga loggar.
    • testbox dyker upp i min logitech media server och jag kör igång en podd (spanarna från 1 1/2 vecka sedan).
    • Efter drygt 10 minuter stannar podden.
    • Jag startar strömmen igen och spolar fram och det är inget problem att fortsätta lyssna
    • Efter ytterligare drygt 10 minuter stannar podden igen.

    Jag har loggar från ovanstående från min klient. Den korta versionen verkar vara att det från min klients sida ser ut som att sr.se:s server helt sonika stänger ned socketen (på ett ordnat sätt) efter drygt 10 minuter. Det leder i sin tur till att klienten (squeezelite) stannar uppspelningen och stänger strömmen (svårt att göra så mycket annat).

    Den något längre versionen är:

    Följande http headers verkar utväxlas mellan min klient och sr vid start av strömmen:

    == Min klients request vid strömstart:
    [18:47:03.652562] stream_sock:413 header: GET /Laddahem/Podradio/p1_spanarna/2016/12/p1_spanarna_20161216_1600_37c7872.mp3 HTTP/1.0
    Cache-Control: no-cache
    Connection: close
    Accept: /
    Host: static-cdn.sr.se
    User-Agent: iTunes/4.7.1 (Linux; N; Debian; x86_64-linux; EN; utf8) SqueezeCenter, Squeezebox Server, Logitech Media Server/7.9.0/1464986354
    Icy-Metadata: 1

    == sr:s svar på ovanstående request
    [18:47:03.730498] stream_thread:176 headers: len: 374
    HTTP/1.1 200 OK
    Server: nginx
    Date: Wed, 28 Dec 2016 17:47:03 GMT
    Content-Type: audio/mpeg
    Content-Length: 39370741
    Connection: close
    Cache-Control: public,max-age=86400
    Last-Modified: Fri, 16 Dec 2016 15:19:11 GMT
    ETag: "efbac2c0af57d21:0"
    X-Powered-By: ASP.NET
    X-UA-Compatible: IE=Edge,chrome=1
    Content-disposition: Attachment
    Age: 21
    Accept-Ranges: bytes

    Efter drygt 10 minuter dyker följande rad upp i min klients log:
    [18:57:23.641742] stream_thread:249 end of stream

    kikar man i koden (viva la open source...) så betyder det att följande anrop returnerar 0:
    n = recv(fd, streambuf->writep, space, 0);

    enligt 'man' sidan för recv så betyder ett returvärde == 0 följande:
    "The return value will be 0 when the peer has performed an orderly shutdown."

    dvs enligt min klient så har sr:s server snyggt och prydligt stängt socketen. Varför detta sker är väl nästa fråga, förväntar sig sr:s server t ex att squeezeboxklienten skall göra något för att inte stänga ned socketen?

    Anders
  • Hej igen.
    Eftersom jag ändå håller på så provade jag att streama ett spanaravsnitt via mplayer också, alltså en helt separat mediaapplikation som inte har något med squeezebox att göra alls.
    Jag får samma beteende där, dvs strömmen stannar, i detta fall 6 minuter och 4 sek in i podden. Jag skickar med loggen från mplayer, den verkar indikera samma sak som squeezelite, dvs att sr:s server stänger ned socketen.

    Playing http://sverigesradio.se/topsy/ljudfil/5949016.mp3.
    get_path('sub/') -> '/home/anders/.mplayer/sub/'
    Filename for url is now http://sverigesradio.se/topsy/ljudfil/5949016.mp3
    Filename for url is now http://sverigesradio.se/topsy/ljudfil/5949016.mp3
    STREAM_HTTP(1), URL: http://sverigesradio.se/topsy/ljudfil/5949016.mp3
    Resolving sverigesradio.se for AF_INET6...

    Couldn't resolve name for AF_INET6: sverigesradio.se
    Resolving sverigesradio.se for AF_INET...
    Connecting to server sverigesradio.se[134.25.4.140]: 80...

    --- HTTP DEBUG HEADER --- START ---
    protocol: [HTTP/1.1]
    http minor version: [1]
    uri: [(null)]
    method: [(null)]
    status code: [302]
    reason phrase: [Found]
    body size: [216]
    Fields:
    0 - Cache-Control: private
    1 - Content-Type: text/html; charset=utf-8
    2 - Location: http://static-cdn.sr.se/Laddahem/Podradio/p1_sp...
    3 - X-UA-Compatible: IE=Edge,chrome=1
    4 - Access-Control-Allow-Origin: *
    5 - Access-Control-Allow-Methods: GET, HEAD, OPTIONS
    6 - Access-Control-Allow-Headers: origin, range
    7 - Access-Control-Expose-Headers: Server, range
    8 - Date: Wed, 28 Dec 2016 19:57:20 GMT
    9 - Content-Length: 216
    10 - Age: 0
    11 - Connection: close
    --- HTTP DEBUG HEADER --- END ---
    Filename for url is now http://static-cdn.sr.se/Laddahem/Podradio/p1_sp...
    Resolving static-cdn.sr.se for AF_INET6...

    Couldn't resolve name for AF_INET6: static-cdn.sr.se
    Resolving static-cdn.sr.se for AF_INET...
    Connecting to server static-cdn.sr.se[83.145.1.98]: 80...

    --- HTTP DEBUG HEADER --- START ---
    protocol: [HTTP/1.1]
    http minor version: [1]
    uri: [(null)]
    method: [(null)]
    status code: [200]
    reason phrase: [OK]
    body size: [1674]
    Fields:
    0 - Server: nginx
    1 - Date: Wed, 28 Dec 2016 19:57:21 GMT
    2 - Content-Type: audio/mpeg
    3 - Content-Length: 39663040
    4 - Connection: close
    5 - Cache-Control: public,max-age=86400
    6 - Last-Modified: Thu, 22 Dec 2016 14:43:58 GMT
    7 - ETag: "995fd9d3615cd21:0"
    8 - X-Powered-By: ASP.NET
    9 - X-UA-Compatible: IE=Edge,chrome=1
    10 - Content-disposition: Attachment
    11 - Age: 44
    12 - Accept-Ranges: bytes
    --- HTTP DEBUG HEADER --- END ---
    Content-Length: [39663040]
    Content-Type: [audio/mpeg]
    Cache size set to 320 KBytes
    STREAM: [null] http://sverigesradio.se/topsy/ljudfil/5949016.mp3
    STREAM: Description: http streaming
    STREAM: Author: Bertrand, Albeau, Reimar Doeffinger, Arpi?
    STREAM: Comment: plain http
    CACHE_PRE_INIT: 0 [0] 0 pre:65536 eof:0

    Cache fill: 0.00% (0 bytes)

    ==> Found audio stream: 0
    Resolving static-cdn.sr.se for AF_INET6...

    Couldn't resolve name for AF_INET6: static-cdn.sr.se
    Resolving static-cdn.sr.se for AF_INET...
    Connecting to server static-cdn.sr.se[62.109.41.162]: 80...

    --- HTTP DEBUG HEADER --- START ---
    protocol: [HTTP/1.1]
    http minor version: [1]
    uri: [(null)]
    method: [(null)]
    status code: [206]
    reason phrase: [Partial Content]
    body size: [1472]
    Fields:
    0 - Server: nginx
    1 - Date: Wed, 28 Dec 2016 19:57:21 GMT
    2 - Content-Type: audio/mpeg
    3 - Content-Length: 1472
    4 - Connection: close
    5 - Cache-Control: public,max-age=86400
    6 - Last-Modified: Thu, 22 Dec 2016 14:43:58 GMT
    7 - ETag: "995fd9d3615cd21:0"
    8 - X-Powered-By: ASP.NET
    9 - X-UA-Compatible: IE=Edge,chrome=1
    10 - Content-disposition: Attachment
    11 - Age: 15
    12 - Content-Range: bytes 39661568-39663039/39663040
    --- HTTP DEBUG HEADER --- END ---
    Content-Type: [audio/mpeg]
    Content-Length: [1472]
    demux_audio: seeking from 0x25D353A to start pos 0x363F3
    Resolving static-cdn.sr.se for AF_INET6...

    Couldn't resolve name for AF_INET6: static-cdn.sr.se
    Resolving static-cdn.sr.se for AF_INET...
    Connecting to server static-cdn.sr.se[83.145.1.98]: 80...

    --- HTTP DEBUG HEADER --- START ---
    protocol: [HTTP/1.1]
    http minor version: [1]
    uri: [(null)]
    method: [(null)]
    status code: [206]
    reason phrase: [Partial Content]
    body size: [1636]
    Fields:
    0 - Server: nginx
    1 - Date: Wed, 28 Dec 2016 19:57:21 GMT
    2 - Content-Type: audio/mpeg
    3 - Content-Length: 39441856
    4 - Connection: close
    5 - Cache-Control: public,max-age=86400
    6 - Last-Modified: Thu, 22 Dec 2016 14:43:58 GMT
    7 - ETag: "995fd9d3615cd21:0"
    8 - X-Powered-By: ASP.NET
    9 - X-UA-Compatible: IE=Edge,chrome=1
    10 - Content-disposition: Attachment
    11 - Age: 44
    12 - Content-Range: bytes 221184-39663039/39663040
    --- HTTP DEBUG HEADER --- END ---
    Content-Type: [audio/mpeg]
    Content-Length: [39441856]
    demux_audio: audio data 0x363F3 - 0x25D3540

    Audio only file format detected.
    Clip info:
    Title: G�ran Everdahl, Jessika Gedin
    Artist: Sveriges Radio
    Album: Spanarna i P1
    Year: 2016
    Comment: G�ran Everdahl: Mini �r Maxi
    Genre: Other

    #get_path('sub/') -> '/home/anders/.mplayer/sub/'

    Opening audio decoder: [mpg123] MPEG 1.0/2.0/2.5 layers I, II, III
    dec_audio: Allocating 8192 + 131072 = 139264 bytes for output buffer.
    MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo
    AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400)

    #Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, II, III)

    Building audio filter chain for 44100Hz/2ch/s16le -> 0Hz/0ch/??...
    [libaf] Adding filter dummy
    [dummy] Was reinitialized: 44100Hz/2ch/s16le
    [dummy] Was reinitialized: 44100Hz/2ch/s16le
    Trying preferred audio driver 'pulse', options '[none]'
    AO: [pulse] 44100Hz 2ch s16le (2 bytes per sample)
    AO: Description: PulseAudio audio output
    AO: Author: Lennart Poettering
    Building audio filter chain for 44100Hz/2ch/s16le -> 44100Hz/2ch/s16le...
    [dummy] Was reinitialized: 44100Hz/2ch/s16le
    [dummy] Was reinitialized: 44100Hz/2ch/s16le
    Video: no video
    Freeing 0 unused video chunks.
    Starting playback...
    Increasing filtered audio buffer size from 0 to 46144
    A: 364.2 (06:04.1) of 2465.0 (41:05.0) 0.1% 0%
    ds_fill_buffer: EOF reached (stream: audio)

    A: 364.2 (06:04.2) of 2465.0 (41:05.0) 0.1% 0%
    ds_fill_buffer: EOF reached (stream: audio)

    A: 364.2 (06:04.2) of 2465.0 (41:05.0) 0.1% 0%
    EOF code: 1

    Uninit audio filters...
    [libaf] Removing filter dummy
    Uninit audio: mpg123
    vo: x11 uninit called but X11 not initialized..

    ##Exiting... (End of file)

    Anders
  • Utomordentligt bra jobbat Anders!
    Hoppas att det gör att man kan hitta felet och följa någon form av standard i fortsättningen. (Följ inte Microsoft!!!).

    Johan
  • Åh, vad jag älskar detta! Inte problemet, förstås, men hur vi gemensamt ringar in vad som kan vara fel, och att vi förhoppningsvis kan hitta en lösning.

    Stort tack, Anders! Jag har bett en kollega på webbutvecklingen och en annan kollega som arbetar med servermiljön att vi tre tillsammans ska titta på detta.

    Ditt test med Mplayer stärker min misstanke om att det kan vara samma grundproblem med Itunes här. Ett problem i att strömma våra podd-avsnitt (istället för att ladda hem dem, vilket de är optimerade för) som uppträder på flera plattformar.

    Johan (och kanske fler av er) har tidigare konstaterat att tiden varierar även när det är samma avsnitt på samma enhet:
    Ibland bara ca 8 minuter, men ofta 15 eller mer. En gång gick hela programmet utan stopp. Jag har hela tiden testat med Godmorgon världen 20161218.

    Det gör att jag inte misstänker att det är hur stor del av avsnittet som initialt kan läsas in som avgör när felet uppstår (vilket spelade in i fjol). En av de saker jag kommer att prata med mina kolleger om, är vad "tidsstämpeln" rent praktiskt innebär (age=21, age=44 ...).

    Denna tror jag är till för att lyssnare ska få uppdaterat innehåll och det är ju jättebra när det gäller en lista med senaste avsnitt och liknande ... Men kan det leda till att den version av filen som ni är anslutna till på något vis upplevs som föråldrat?

    Efter lunch hoppas jag att mina kolleger har hunnit kolla på loggen, för de är bättre på att läsa sådana än vad jag är!

    Anders (om du vill och hinner):
    Att jämföra vilka skillnader det blir i loggarna med en och samma fil vid olika tillfällen (gärna med Mplayer som du fick ut så bra data från!) kanske kan ringa in felet? Notera vid vilken tid felet uppstår för att se ifall det finns någon korrelation mellan Age, Content-Range, Content-Length eller bytes for output buffer och speltid ...

    Annika Webbmaster
  • Hej.
    Jag tror du har rätt i att det är samma grundproblem som det med iTunes som du refererar till. Jag tror dock inte att du är rätt ute när du försöker korrelera tidsstämpeln med felet (men vi får se...)

    Ev hinner jag göra några jämförelser med samma fil ikväll, återkommer i så fall om det.

    Jag gjorde däremot några extra tester häromdagen och fick fram följande:

    1. VLC beter sig på samma sätt som mplayer och squeezelite (dvs stänger ned efter en tid)
    2. Jag loggade TCP/IP trafiken mellan min dator och sr:s server vid ett tillfälle när podden avbröts. Det man kan se i loggen är att trafiken är symmetrisk under tiden allt rullar på men plötsligt så skickar sr:s server ett konstigt paket (kan för lite om TCP/IP för att säga något mer bestämt än 'konstigt'). Efter ytterligare ett par paket med ljuddata skickar sedan sr:s server ett paket med FIN flaggan satt. Det verkar vara TCP's sätt att säga "Nu tänker jag inte säga något mer men jag lyssnar klart på vad du har att säga". När klientens TCP stack får detta paket så agerar den som förväntat, dvs stänger ned uppkopplingen med ett "end-of-stream" meddelande -> no more pod.

    Annika, om du eller någon annan på sr vill ha paketloggen (en pcap fil från Wireshark) så hör av dig på min mailadress så kan jag posta den.

    Anders
  • Tiden bara rusar iväg!

    Jag och webbutvecklaren har bollat en del tankar. Den stora förändringen som vi har genomfört, är att vi, i oktober, flyttade ut poddfilerna till ett CDN, adressen static-cdn.sr.se. Under de första veckorna var detta av och till avslaget, eftersom det fanns olika saker vi behövde skruva på, vilket kan förklara att felet inte märktes förrän senare hos några av er.

    Kanske CDN:et tolkar era anrop som att filen ska laddas ned, och efter tio minuter eller så menar att ni bör vara klara och avbryter processen? (Men varför i så fall vid olika tidpunkt olika gånger?)

    Anders:
    Just nu (strax innan nyårshelgen) är det ingen som kommer att kika på loggen från VLC. Vi kan troligen återskapa likande själva, och då behöver vi den inte. Men konstiga paket i juletid blir man ju alltid nyfiken på, så det är möjligt att mina kolleger vill ha detta smile

    Vi hörs nästa år! (Skönt att det i alla fall går att spola förbi avbrottspunkten denna gång - men det vore väldigt skönt att lösa detta!)

    Annika Webbmaster
  • Hej. Även jag har detta problem nu(igen)

    Jag streamar med via Squeezebox.
    En Logitech Media Server Version: 7.9.0 installerad på Windows Essentials 2012R2-server
    Jag har även testat version 7.7.5/7.9.0 på både Windows Essentials 2012R2 och Windows10, men med samma resultat.
    Internetanslutningen(200/20) har varit oförändrad i flera år och utan problem
    SVT-Play, Netflix, HBO.. fungerar felfritt.och som någon nämnde ovan, så fungerar streamad radio och Spotify via Squeezebox helt felfritt.
    Routern är helt oförändrad. Dock har jag nu provat att lägga till/ta bort portar som Squeezeboxservern använder(i mitt fall 900, 9010 och 3483), men utan resultat.
    Jag har anslutit Squeezebox-resivers och Squeezebox-Touch till LMS..

    Förra gången detta fel uppstod var väl för något år sedan och som jag förstod berodde på att ni ändrat hur ni streamar..
    Det beskrevs rätt bra här: http://forums.slimdevices.com/showthread.php?10... , och att här fanns det en lösning.

    Problemet är som beskrivits ovan, att pod'en startar som den skall, men stoppas efter 12-15 minuter. Man får då starta dn på nytt från början och hoppa fram till stället den slutade. Det spelar ingen roll vilken Pod jag kör(Spanarna, Snedtänkt, Vetenskapradion Forum...osv.) Problemet uppstod någon gång efter sommaren känns det som..

    Jag körde, när problemet uppstod Logitech Media Server Version: 7.7.5, men har uppdaterat till version 7.9.0 efterhand. Nu tror jag inte servern i sig är själva problemet - Servern(som jag har förstått det) tillhandahåller endast listan av Poddar. När man väl valt en Pod, streamas den direkt till 'apparaten'(Touch, Boom, Receivern).

    Jag skickar med en liten logg(Endast Pod-appens logg) från Squeezeboxservern. Mest för att visa en Pod-länk. Dock kan man se hur det slutar - när playtime => 0, då stoppar podden.

    [17-01-04 19:10:22.0006] Slim::Plugin::Podcast::Plugin::_trackProgress (149) Updating podcast progress state {
    player => "Squeezeboxvardagsrum",
    playtime => "664.021820083618",
    url => "http://static-cdn.sr.se/Laddahem/Podradio/p1_ve...",
    }
    [17-01-04 19:10:27.0010] Slim::Plugin::Podcast::Plugin::_trackProgress (149) Updating podcast progress state {
    player => "Squeezeboxvardagsrum",
    playtime => "669.022346273422",
    url => "http://static-cdn.sr.se/Laddahem/Podradio/p1_ve...",
    }
    [17-01-04 19:10:32.0006] Slim::Plugin::Podcast::Plugin::_trackProgress (149) Updating podcast progress state {
    player => "Squeezeboxvardagsrum",
    playtime => "674.022205129623",
    url => "http://static-cdn.sr.se/Laddahem/Podradio/p1_ve...",
    }
    [17-01-04 19:10:37.0007] Slim::Plugin::Podcast::Plugin::_trackProgress (149) Updating podcast progress state {
    player => "Squeezeboxvardagsrum",
    playtime => "679.022364154816",
    url => "http://static-cdn.sr.se/Laddahem/Podradio/p1_ve...",
    }
    [17-01-04 19:10:38.8816] Slim::Plugin::Podcast::Plugin::songChangeCallback (122) Setting up timer to track podcast progress...
    [17-01-04 19:10:43.0012] Slim::Plugin::Podcast::Plugin::_trackProgress (149) Updating podcast progress state {
    player => "Squeezeboxvardagsrum",
    playtime => 0,
    url => "http://static-cdn.sr.se/Laddahem/Podradio/p1_ve...",
    }

    Vore trevligt med en lösning denna gången också smile

    Stefan Nelander
  • Hej igen!

    Stefan och många av er andra ser likheter med fjolårets problem.

    Dessa berodde på att vi införde Varnish) och den tekniken inte fungerade för er. Lösningen var att koppla era enheter förbi Varnish och med hjälp av ett par av er som felanmälde kunde vi se vilka user agents som olika Squeezebox-enheter hade och skapa undantag för just er.

    Min första tanke när jag såg era felrapporter var att det var samma fel igen och att vi vid någon uppdatering missat att få med (den väldigt korta) listan med undantag för Varnish. Men relativt snart såg vi att det fanns en stor skillnad. När problemet berodde på Varnish, såg det annorlunda ut. Felet var mer regelbundet. Samma fil bröts vid exakt samma tidpunkt hos samma användare. Det gick inte att spola förbi den punkten.

    Den här gången varierar tidsspannet mer. Johan testade med samma fil flera gånger. Ibland bara ca 8 minuter, men ofta 15 eller mer. En gång gick hela programmet utan stopp.

    Så skulle det helt enkelt inte bli om felet berodde på Varnish. Teorin, än så länge, är att detta har med en annan teknik att göra, CDN. Tyvärr har vi ännu inte hunnit ge detta problem den tankemöda som krävs, eftersom olika nyckelpersoner (inklusive undertecknad, som har bäst överblick över era felanmälningar) har haft semestrar, men jag har en del idéer över saker som jag vill testa.

    Hur har ni lagt in våra URL:er?
    En sak som jag nog inte riktigt har fått kläm på, är hur ni hämtar våra poddar. Alltså vilka länkar ni använder och hur ni "berättar" för er Squeezebox att det är detta avsnitt av detta program ni vill höra. Har ni lagt in våra URL:er manuellt (till exempel i denna podcast-app)? Eller går ni via en databas (till exempel via Tunein-appen)?

    Berätta mer!

    Undantagen: Avsnitten ni kan avlyssna i sin helhet
    Några av er har skrivit att ni undantagsvis kan lyssna utan avbrott.
    Jag är intresserad av vilka program det är ni faktiskt lyckas lyssna på i sin helhet. Att riktigt korta avsnitt som Dagens dikt och Tankar för dagen kan avlyssnas i sin helhet är förstås inte konstigt, men vilka program är det som är längre - och lyckas komma fram i sin helhet?

    Och om de inte kan spelas upp i sin helhet, så vilket är det längsta sammanhållna sjok ni lyckats höra sedan ni märkte problemet? Vilket avsnitt av vilket program? Hur länge gick det att lyssna?

    Jag förstår att detta inte heller är speciellt lätt att komma ihåg, och då är det ju inget att göra något åt. Men fråga kan jag ju wink

    Är det program ni först påbörjat lyssningen av, men sedan aldrig hann klart och nu tar upp på nytt?

    Väldigt gamla avsnitt (eller väldigt smala) som det kanske är få andra som lyssnar på?

    Eller tvärtom, senaste P3 Dokumentären och veckans avsnitt av Spanarna, där det förmodligen är många som lyssnar?

    Svara om ni kan! Det kan eventuellt vara relevant, nämligen ...

    Annika Webbmaster
  • Det finns flera sätt att komma åt podsändningar i Squeezeboxen. Så här gör jag:

    Jag lägger till URL:erna manuellt i spelarens webbgränssnitt. Jag gissar att de lagras på mysqueezebox.com då jag inte kör någon egen server.
    Bild: http://i.imgur.com/mSNXVnm.png

    Spelaren läser sen RSS:en från er och presenterar en lista på avsnitt.
    Bild: http://i.imgur.com/jn2Z3WH.png

    Clas
  • Tack Clas!

    Det är i alla fall inget problem som är kopplat till att det är fel länk ...

    Jag drog problemet för den webbutvecklare som kanske har bäst överblick när det gäller alla förändringar som skett med vår plattform det senaste året och insåg att jag behöver bli mer säker på en punkt. Hur fungerar andra poddar än våra?

    Johan skrev:
    Om jag lyssnar på annan podd (teknikpodden, har bara den också) så stannar det inte.

    Det är i alla fall tillräckligt långa avsnitt för att problemet skulle uppstå om det var ett generellt problem.

    Anders skrev:
    Jag lyssnar nästan uteslutande på sr's poddar så jag kan inte gå i god för om övriga poddar beter sig felfritt. Jag är ganska säker på att jag har haft avbrott även när jag lyssnat på 'Värvet' men inte 100.

    Har du lyssnat på Värvet mer sedan du skrev detta i slutet av december? Det vore intressant att bli 100!

    Erik, Stefan, Clas och Supporter (som ju lyckades återskapa ett liknande beteende med Radiotray) ... Lyssnar någon av er även på andra poddar? Hur går det i så fall?

    Här är länkar till flödet för de två icke Sveriges Radio-poddar som nämnts:

    Teknikpodden:
    http://enpoddomteknik.libsyn.com/rss

    Värvet:
    http://rss.acast.com/varvet

    Annika Webbmaster
  • Hej,

    Jag lyssnar nästan enbart på SR-poddar och felet uppträder på alla jag lyssnar på. En icke-SR podd som jag aldrig fått problemet på (och avsnitten är timslånga) är This American Life (https://www.thisamericanlife.org). För den har problemet aldrig uppträtt.

    Erik Frisk
  • Tack! Det stärker mig i misstanken att felet är helt kopplat till tekniska förändringar hos oss.

    Annika Webbmaster
  • Ni som har olika nätverk att testa på (eller kan strypa uppkopplingen):
    Jag funderar över om felet kan bli värre ju bättre uppkoppling ni har, så att en sämre lina skulle göra att ni kan lyssna längre tid innan avbrottet uppträder ...

    Att felet uppträder vid olika tidpunkter i samma avsnitt, hos samma lyssnare, kräver ju en förklaring, och fluktuationer i nätverket skulle kunna vara en sådan förklaring.

    Det jag funderar över är om våra system tolkar era anrop som ett nedladdningsförsök och stänger ned när vi anser att hela filen är nedladdad. I så fall borde en snabbare uppkoppling ge större problem.

    Tror någon av er att ni kan bekräfta eller avfärda denna hypotes?

    Annika Webbmaster
  • Hej.
    Nu har jag haft möjlighet att göra några ytterligare tester. Eftersom jag har sett samma beteende (streamade poddar avbryts efter 3-15 min) då jag använt både squeezebox/squeezelite, mplayer och vlc så gjorde jag testerna med mplayer eftersom det är lättare att dona med.

    Mina slutsater är följande (se nedan för detaljer om vad jag har testat):

    • Det verkar spela roll hur klienten (mplayer) cachar data. I defaultläge så använder mplayer en cache på 320 kB. Då verkar saker och ting gå dåligt (strömmen stannar). Om jag tvingar mplayer till att inte cacha data alls (genom flaggan -nocache) så kan jag lyssna på hela podavsnitt utan avbrott.
    • Det verkar spela roll hur cdn lösningen är uppsatt. Den cdn som sr använder funkar inte med mplayers defaultsetting av data cachning. Detsamma gäller för den cdn som Värvet använder (stitched-files.bwh9c8255b4.netdna-cdn.com[94.31.29.248]: 80) Däremot verkar den cdn som teknikpodden använder (hwcdn.libsyn.com[69.16.175.10]: 80) fungera ihop med mplayers default cache beteende
    • Vissa podcasts verkar inte använda en cdn och där ser det heller inte ut som att mplayer använder någon cache på klientsidan, t ex podden Invisibilia.

    Så, antingen är det en bug på klientsidan (säg t ex att mplayer, vlc och squeezebox/squeezelite använder samma underliggande bibliotek för att spela upp mp3 strömmar och därför beter sig på samma sätt) eller så är det en bug/konfigurationsproblem för hur cdn servicen är uppsatt.

    Om jag skulle gissa så skulle det bli att kombinationen av att klienten cachar strömmen (dvs hämtar 'chunkar' av data i taget) och hur cdn servicen förväntar sig att klienter uppför sig (laddar ned hela avsnitt eller inte cachar alls) gör att det inte funkar. Vid något tillfälle tycker cdn servern att det tar för lång tid mellan två klientrequests och stänger strömmen.

    Som jag skrev i ett tidigare inlägg kollade jag på den råa tcp/ip trafiken vid ett tillfälle då poddströmmen stannade och kan där se att servern hos sr explicit säger 'tack-och-hej' till min klient och därmed avslutar strömmen.

    /Anders

    = Följande saker är testade (alla genom mplayer):

    == Senaste spanaravsnittet (http://sverigesradio.se/topsy/ljudfil/5969609.mp3)

    Test 1 (utan tweakning av mplayer)
    Stannar efter 6 min och 22 sek

    Test 2 (flaggan -nocache använd när jag startade mplayer)
    Hela avsnittet spelar utan problem

    I båda testerna ovan så landade min request hos en server med namnet static-cdn.sr.se, dock med olika ip-nummer i respektive fall.

    == Avsnitt #258 av Värvet ( http://media.acast.com/varvet/-258-mansherngren...)

    Test 1 (utan tweakning av mplayer
    stannar efter 3 min 12 sek

    Test 2 (exakt samma som test 1)
    stannar efter 5 min 8 sek

    Test 3 (flaggan -nocache används till mplayer)
    hela avsnittet spelar utan problem

    Test 4 (samma som test 1 och 2)
    stannar efter 5 min 6 sek

    == Teknikpodden (http://traffic.libsyn.com/enpoddomteknik/epot-7...)

    Test 1 (utan twekning av mplayer)
    Hela avsnittet spelar utan problem

    Test 2 (repetition av test 1)
    Hela avsnittet spelar utan problem

    == Podden 'Invisibilia' avsnitt 'outside in' (https://play.podtrac.com/npr-510307/npr.mc.trit...)

    Test 1 (utan tweak till mplayer)
    i princip hela avsnittet spelas upp men när det är ca 4 min kvar (efter 1h speltid) så dyker följande loggrader upp:
    [tls @ 0x7f5f2923d3c0]A TLS packet with unexpected length was received.
    [tls @ 0x7f5f2923d3c0]The specified session has been invalidated for some reason.
    Min gissning är att ovanstående är orelaterat till det som denna tråd berör.

    == Direktlyssning av p1 (http://sverigesradio.se/topsy/direkt/132-hi.mp3)
    Test 1
    Verkar gå bra, denna request landar i servern http-live.sr.se[134.25.4.151]: 80

    Anders
  • Jag lyssnar mestadels på poddar från andra källor än SR och för mig så dyker det här problemet upp endast hos er.

    Testade lite om jag kunde hitta något lite längre program som spelades utan stopp och hittills så har jag hittat ett.
    P3 Dokumentär (avsnittet om Brommagymnasiet) spelades rakt igenom utan problem.

    Dessa som jag spelat de senaste dagarna stoppade alla:
    P4 Dokumentär (MrX del2)
    Spanarna (senaste avsnittet)
    USA-valpodden (senaste avsnittet)

    Clas
  • Anders:
    Oj, intressant!

    Vi ser ifall det verkligen är just cdn-relaterat, eller om det finns någon annan gemensam nämnare hos Värvet och våra filer. (Vi kan t ex ha ändrat i vår metadata också.)

    Här är samma avsnitt av Spanarna dels via vårt cdn (det sätt vi numera levererar poddfiler i era rss-flöden), och dels med en länk som går förbi cdn:et, som vi gjorde tidigare!

    Vanliga länken:
    http://static-cdn.sr.se/Laddahem/Podradio/p1_spanarna/2016/12/p1_spanarna_20161216_1600_37c7872.mp3

    Samma avsnitt utan cdn:
    http://static.sr.se/Laddahem/Podradio/p1_spanarna/2016/12/p1_spanarna_20161216_1600_37c7872.mp3

    Länkarna blir kanske trunkerade i detta forum, men den väsentliga skillnaden är http://static-cdn.sr.se/ respektive http://static.sr.se/ och det framgår ju!

    Om det är just cdn-relaterat, borde det gå att lyssna på den senare länken även med cache påslaget.

    Clas:
    Ditt resultat visar att populära/aktuella avsnitt - till vilka jag räknar alla i ditt exempel - både kan drabbas och förskonas från avbrotten.

    Jag funderade annars på om det var större möjlighet att få höra ett helt avsnitt ifall detta inte fanns cachat på vårt CDN. Hade det varit ett udda avsnitt som Nyhetsmagasinet Utblick sápmi från 26 augusti 2012 som funkade, hade misstanken kvarstått ...

    Tack!

    Annika Webbmaster
  • Länkarna blir kanske trunkerade ...

    Jag har just lärt mig att komma runt detta problem! Ett litet steg för Sveriges Radio, men en bra sak för vår webbsupport!

    Off topic, jag vet, men jag blev rätt glad lol

    Annika Webbmaster
  • Jag testade att spela "Nyhetsmagasinet Utblick sápmi från 26 augusti 2012" också, men det känns som att det inte gav ett resultat som ger någon klarhet.

    Programmet gick så långt att jag trodde att det skulle spela utan avbrott men nånstans kring 25 minuter så stoppade den. Bara för att verifiera att felet går att återskapa så startade jag om radion och testade att spela samma fil en gång till. Denna gång så spelade den hela programmet till slut utan problem.

    Clas
  • Jag testade att spela "Nyhetsmagasinet Utblick sápmi från 26 augusti 2012" också...

    Hoppas att det var intressant! wink (Om du talar samiska blir det förstås en annan lyssningsupplevelse än för mig som inte behärskar språket, trots samiska rötter.)

    Jag håller med om att vi utifrån dina resultat endast kan säga att programmen stoppar ofta, men inte alltid och att detta gäller både kioskvältare och mer ovanliga avsnitt.

    En lyssnare med Squeezebox - utan problem!
    Jag frågade en lyssnare med Squeezebox som hört av sig om annat ifall han hade stött på detta fel, vilket han aldrig hade gjort. Det är ju intressant!

    Jag har därför frågat vad han har för variant av Squeezebox.

    Nu verkar det i och för sig inte hänga samman med vilken modell man har ... Stämmer denna lista med Squeezebox-enheter där ni fått problemet? (Att felet kan återskapas även på Itunes, VLC och MPlayer tyder ju också på att det inte är modell-beroende, men det är likväl intressant att se om någon av er har samma som han använder!)

    Squeezebox Radio: Johan (2 st), Clas, Anders
    Squeezbox Duet: Anders
    Squeezelite-emulerad på PiCorePlayer v3.02: Anders (2 st)
    Squeezebox Touch: Stefan
    Squeezebox Boom: Stefan
    Squeezebox Receiver: Stefan

    Erik, vad har du för pryl?

    Är det någon annan del av kedjan som är mer relevant än själva "radion"? Jag har fått intryck av att era "maskinparker" är en väldigt spretig flora. Flera av er har dessutom testat Logitech Media Server respektive mysqueezebox, LMS körs på olika operativsystem och så vidare ...

    Jag kommer inte på vad det är jag ska ta reda på om den här lyssnarens miljö, annat än just modellen av spelare ...

    Geografin
    Något som är väldigt intressant är att denna lyssnare befinner sig i ett annat land och därmed går mot ett annat cdn.

    Jag kikade på de IP-adresser som jag kan se i forumet (det vill säga var era datorer troligen geografiskt befann sig när ni skrev hit - även om detta går att manipulera) och alla är från Sverige - men olika delar av landet. (Norr och söder, storstad och glesbygd ...). Jag ska kolla upp lite hur det funkar med cdn:et, om det finns någon skillnad mellan hur det cdn min icke-drabbade lyssnare kommer till är konfigurerat och de (troligen olika) cdn ni går mot ser ut, förutom att hans cdn troligen har rätt få Sveriges Radio-filer cachade sedan förut.

    Kampen går vidare för en avbrottsfri lyssning!

    Annika Webbmaster
  • Hej,

    Jag har ett antal Squeezebox Duet. LMS kör på en iMac med senaste OS.

    Stor eloge Annika för ditt engagemang och glada humör!

    Erik Frisk
  • Stefans data är intressant. trackProgress (149) Updating podcast progress state medför att allt rullar på.

    Problemet uppstår efter songChangeCallback (122) Setting up timer to track podcast progress

    (Mest utklippt för vår egen felsöknings skull!)

    Annika Webbmaster
  • Hej igen.
    Jag har gjort några nya tester och de verkar tyvärr inte stämma med min teori om huruvida cachen på mplayer är uppsatt och hur cdn hanterar detta. Jag har fått strömmar som stannar oavsett om min klient cachar data eller inte och både när jag går mot cdn och inte sad

    Jag har tittat en del på den råa tcp trafiken i Wireshark. Det ser verkligen ut som att sr:s servrar helt enkelt plötsligt bestämmer sig för att min klient inte längre skall ha någon data och avslutar strömmen genom att sätta en 'FIN' flagga hux-flux i ett tcp paket.
    Jag har inte sett något tidigare i tcp trafiken som skulle indikera varför detta sker.

    Man kan notera är att sr:s servrar öser på data tills det är helt fullt på klientsidan, så fort klienten har betat av en smula data så smäller det till igen. Det här är troligen inget fel men man kan konstatera att sr:s servrar inte har någon egen flödeskontroll och blankt ignorerar att det är en ljudström som spelas upp och att data därför inte kommer att ätas upp snabbare än ca 192 kb/s på klientsidan. Servern använder i praktiken klientens 'receive window' som flödeskontroll och hanterar alltså strömmningen precis som om det var en vanlig nedladdning av en fil och klienten alltså vill ha data så fort som möjligt (istället för en stadig ström med lägre hastighet).

    Det skulle kunna tala för att servern stänger ned strömmen för att den 'tröttnar' på att serva en 'fil' till klienten när den tycker att klienten bör ha haft tillräckligt lång tid på sig att ta emot den (eftersom servern inte verkar ta hänsyn till att det är en ljudström...). Jag har gjort några tester som indikerar att längre program spelar längre tid innan de stoppar men det är för mycket osäkerhet för att kunna säga att det verkligen är så.

    Skickar med en skärmdump över de sista skälvande tcp paketen i en ström som stoppade mitt i (går mot http://static.sr.se/). Det paket som är blåmarkerat kommer från sr:s server och det är detta som talar om för klienten att det är dax att packa ihop och gå hem.

    /Anders

    ps Jag tror att din (Annika) kommentar ovan är bakvänd, jag tror att eftersom strömmen stängs så kommer songChangeCallback att anropas (spelaren tror ju att sången är slut...) så jag skulle säga att det är troligast att problemet uppstår precis innan songChangeCallback. ds

    pss Den eventuella uppsidan av detta är att jag nu är mycket mer bekant med tcp än jag hade tänkt bli... smile även jag tackar för ett bra engagemang från dig Annika dss

    Bifogad fil:
    https://kundo.se/site_media/attachment/forum_88...

    Anders
  • Jag tycker inte att lyssnarna ska behöva felsöka detta. Som Anders skriver så ger testning olika resultat. Kan det inte vara så att de NGINX-servrar som används i CDN:et inte är det mest optimala för streamning av mp3? Det som i detta fallet levereras är progressiv nedladdning, och att de lyssnare det handlar om tills det hela är löst helt sonika får sätta klientens buffert till kanske uppåt "jag vågar inte nämna siffran"... om man nu inte vill "ladda ned" i stället. Jag satte bufferten till 57600 kB i mplayer och då slapp jag åtminstone avbrott för en timmes långa program, hoppas jag, för det går inte sitta och testa detta i evigheter - testat en gång över h$$p://static-cdn.sr.se. Det har diskuterats på slimdevices community hur tweakning av bufferten kan gå till. Inte heller det den bästa lösningen för lyssnaren kan tyckas. Erik har i en annan tråd tipsat om en annan tråd från samma forum där det finns andra intressanta tips. Men huvudproblemet ligger egentligen som framgår någon annanstans.

    supporter
  • Anders:
    Jag har fått strömmar som stannar oavsett om min klient cachar data eller inte och både när jag går mot cdn och inte

    Vilket vi är enormt tacksamma över att du rapporterar in! Våra egna tester har givit avbrott på static och inte på cdn-static vid något tillfälle och jag funderade över om vi på Sveriges Radio gick mot ett annat cdn eller på annat vis gjorde fel när vi testade, men att du rapporterar in samma beteende gör att jag mer vågar lita på att vi tittar på rätt grejer!

    Det ser verkligen ut som att sr:s servrar helt enkelt plötsligt bestämmer sig för att min klient inte längre skall ha någon data och avslutar strömmen genom att sätta en 'FIN' flagga hux-flux i ett tcp paket.

    Kanske filens tidsstämpel spelar in och vi levererar ljud korrekt tills "filen är för gammal".

    jag skulle säga att det är troligast att problemet uppstår precis innan songChangeCallback

    Låter rimligt.

    Man kan notera är att sr:s servrar öser på data tills det är helt fullt på klientsidan, så fort klienten har betat av en smula data så smäller det till igen. Det här är troligen inget fel men man kan konstatera att sr:s servrar inte har någon egen flödeskontroll och blankt ignorerar att det är en ljudström som spelas upp och att data därför inte kommer att ätas upp snabbare än ca 192 kb/s på klientsidan.

    Bisak:
    128 kb/s när det gäller poddfil wink
    Viktigare:
    Frågan är hur en request ska se ut för att servern ska förstå att det är "spela upp" och inte "ladda ned" som gäller. Borde det inte räcka att säga no-cach?

    Av din post från 28 december framgår vilka headers som utväxlas mellan klienten Squeezelite och oss:
    Cache-Control: no-cache säger klienten och vi svarar Cache-Control: public,max-age=86400

    Det ligger ju i vårt eget intresse också att inte hålla på att gödsla med data klienterna inte har frågat efter, så vi vill verkligen förstå hur vi bäst löser detta, oavsett var i kedjan missförståndet uppstår!

    Annika Webbmaster
  • Supporter:
    Den intressanta tråden i Slimdevice som Erik tipsade om, rör felet från i fjol med Varnish.

    Då hade vi inte hade gjort lika stora förändringar i miljön som vi har genomfört den senaste tiden, så det gick relativt enkelt att förstå sambandet mellan Varnish och de drabbade enheterna. Viss felsökning ihop med lyssnare behövde vi göra även då.

    Denna gång är det ett annat fel. Båda felen hänger samman med att Sveriges Radio skickar ljudfilerna som vore det för nedladdning och inte streming, men uppenbarligen har vi gjort på det viset långt innan problemet med Varnish uppstod, och vi har fortsatt att göra på samma vis (för vi löste aldrig problemet, utan kopplade VLC, mplayer, Squeezebox och ett par enheter till förbi Varnish).

    Jag tycker inte att lyssnarna ska behöva felsöka detta.
    Ingen behöver felsöka, men jag är övertygad om att felet löser sig snabbare ifall vi får er hjälp, och försöker vara tydlig med att vi är väldigt tacksamma över er hjälp. Vi hade inte vetat om felet om ni inte hade rapporterat det.

    de lyssnare det handlar om tills det hela är löst helt sonika får sätta klientens buffert till kanske uppåt "jag vågar inte nämna siffran"... om man nu inte vill "ladda ned" i stället.

    Ladda ned går i mplayer och VLC, men det går väl inte ens i Squeezebox? Och att labba med gigantisk buffert låter verkligen inte som rätt väg att gå.

    Ni med Squeezebox:
    Ett annat sätt (som en tillfällig work around) kanske är att testa att hämta poddfilerna på annat vis än vanligt. Har någon av er testat hur Tunein-appen för Squeezebox funkar? Ingår våra poddar? Blir det samma typ av avbrott?

    Men huvudproblemet ligger egentligen som framgår någon annanstans.

    Någon förändring i vår tekniska lösning ger problem för vissa klienter som spelar upp nedladdningsbara MP3-filer. Vi felsöker själva, men vi felsöker enormt mycket bättre med er hjälp.

    Vi vill inte ha felet. Ni vill inte ha det. Konstigare än så är det inte.

    Annika Webbmaster
  • Hej igen.

    Kanske filens tidsstämpel spelar in och vi levererar ljud korrekt tills "filen är för gammal".
    Jag har svårt att se att detta skall spela in, då borde ju gamla avsnitt inte spelas alls?

    Frågan är hur en request ska se ut för att servern ska förstå att det är "spela upp" och inte "ladda ned" som gäller. Borde det inte räcka att säga no-cach?
    Jag lutar åt samma håll som @supporter, dvs att det som sr just nu levererar inte är 'streaming' utan helt enkelt filnedladdning (som råkar ta lika lång tid som programmet är långt eftersom klienten hela tiden måste strypa dataflödet från servern. I parentes kan jag säga att den cdn som värvet använder verkar fungera ungefär på samma sätt som sr:s.

    Av din post från 28 december framgår vilka headers som utväxlas mellan klienten Squeezelite och oss:
    Cache-Control: no-cache säger klienten och vi svarar Cache-Control: public,max-age=86400

    Jag vet inte vad "Cache-Control: no-cache" betyder i klientens http request men det verkar ju inte påverka hur servern (efter en trolig redirect) faktiskt levererar data.

    Ladda ned går i mplayer och VLC, men det går väl inte ens i Squeezebox? Och att labba med gigantisk buffert låter verkligen inte som rätt väg att gå.
    Jag håller med, det skulle inte fungera för mig.

    Jag börjar nå vägs ände med testning från mitt håll. Som jag nämnde ovan så lutar jag åt slutsatsen att något är skumt med hur sr levererar data. Jag har några sparade pcap filer från Wireshark om någon på sr är intresserad, annars krävs nästan att sr kan sätta upp någon specifik podlänk som just vi drabbade kan strömma medan någon på sr loggar trafiken för att se vad som händer hos er.

    MvH
    /Anders

    Anders
  • Jag testade Tunein. Det fanns inte många SR-poddar där men det gick att lägga till egna. Jag testade att lägga till "Spanarna" och lyssnade på det senaste avsnittet. Det stoppade på samma sätt som när man spelar via det inbyggda podgränssnittet.

    Clas
  • Hoppsan! -och sent omsider.

    Jag var en av dem som fick hjälp med det tidigare, likartade felet, i Radiotray för ett par år sedan. Efter en resa över jul och nyår har felet - nästan - kommit tillbaka. Podsändningar bryter, lite olika efter hur lång tid, medan de ibland; som söndagens Godmorgon Världen körde på utan uppehåll i två timmar under söndageftermiddagen.

    Hade fått ett mail om att Radiotray-tråden hade lagts ned (eftersom alla problem var lösta? ;P) och sökte just upp det, hamnade här. Tyvärr (och desto bättre) är tråden redan så lång att det är svårt att få överblick; men så mycket verkar jag få med mig; att någon lösning - eller idé om själva problemets natur - dit har ni ännu inte kommit.

    Mitt enda bidrag, just nu, är tyvärr bara att lägga till; Alltså; Radiotray fungerar lite hur den vill och helt oförutsägbart, åtminstone från just denna dator, detta operativsystem: Ubuntu 32-bit 12.04.5 (sic!) - men när jag får tid skall jag kolla andra enheter också.

    mvh,

    håkan
  • Ännu en med en Logitech Squeezebox och problem med poddar som stoppar efter 10-15 minuter. Precis som Johan i början av tråden. Det verkar inte finnas nån lösning ännu?
    Bengt
  • Inatt fick jag starta om senaste "Lanzkampen" två gånger för att kunna höra hela. Snabbspolade 1a och 2a omstarten till där det stoppade senast (omkring 8 resp 15 min efter start).
    Idag kunde jag lyssna på hela "På Minuten" utan stopp!
    Har ni gjort nåt som gör att det fungerar nu?
    Bengt
  • Jag vet inte om jag inbillar mig, men jag tycker att problemet har blivit värre den senaste tiden. När senaste avsnittet av Kaliber stoppade för tredje gången på ett 33-minuters program, då gav jag upp.
    Clas
  • Jo jag kan hålla med. Lyssnat på Språket några gånger. Hinner stanna tre gånger på ett avsnitt.
    Jag förstår att det jobbas på detta, men det har gått lång tid nu sedan problemen började.
    Får du inte fart på teknikerna Annika?
    Johan
  • Hej alla!

    Det arbetas, och i fredags gjorde vi några förändringar som verkar ha minskat avbrotten i de VLC-enheter vi testar med. Men jag behöver prata med lite olika personer runt om i huset för att få bättre inblick i vad vi gjorde och om det verkligen var i fredags.

    Bengt: Du skrev Inatt fick jag starta om senaste "Lanzkampen" två gånger ... Du talar om avsnittet från i fredags, och natten mot lördag, eller hur? I sådana fall borde det inte vara någon skillnad, de förändringar vi gjorde skedde i fredags (utgår jag från - men behöver få bekräftat från kolleger). Eftersom felet inte är reproducerbart varje gång, kan det ju ha varit en tillfällighet att På Minuten fungerade i helgen.

    Clas: När var det du lyssnade på Kaliber? I helgen eller tidigare i veckan?

    Johan: Språket ... Var det nu i helgen du fick så många avbrott?
    Annika Webbmaster
  • Jag försökte lyssna på kaliber sent på fredag kväll.
    Clas
  • Tack. Då vet jag att dessa "fredags-förändringar" (medvetet luddigt utryck, jag är nämligen inte insatt, men försöker bli!) inte var nog.

    I fredags identifierade vi ytterligare inställningar som vi vill förändra, men som vi valde att vänta med, eftersom vi helst undviker större förändringar innan helger.

    Får du inte fart på teknikerna Annika?
    Den kollega som var bäst insatt in i ärendet gick och blev pappa några vecka tidigare än vad han hade planerat (inte alarmerande tidigt, allt är väl), och prioriterade andra saker än att felsöka poddfiler.
    Annika Webbmaster
  • Jag fick avbrott fredag o lördag, men även tidigare.

    Johan
  • Tack. Förändringen som gjordes skedde sent på fredagen, så det som möjligen skulle ha kunnat hända, är att någon av er noterat en viss förbättring efter det.

    Det vi har ändrat är en parameter som håller sessionen öppen för streaming av långa filer. Den är default på 600 sek, vilket vi nu har ändrat till 1,5 timme. Men detta borde inte ha påverkat ert problem, eftersom det är i en annan del av "streaming-kedjan" som ert fel ligger.

    Men, som sagt, vi har identifierat ett par andra ställen vi bör skruva på. Jag hör av mig när vi har gjort detta.
    Annika Webbmaster
  • Hej igen!

    Tänkte bara berätta att vi håller på att testa lite fler saker. Ni är inte bortglömda.

    Annika Webbmaster
  • Fint.Jag har som sagt svårt att komma vidare hemifrån. Hör av er om ni vill att jag skall testa något specifikt.


    Anders
  • Jag har varit sjuk så jag har inte kunnat svara tidigare.
    "Fredagsförändringarna" verkar som sagt inte gjort nån skillnad, fortfarande stopp efter ca 10-12 minuter, sen får man starta om och "snabbspola" till ungefär där det tog stopp senast.
    Funkar utmärkt från webben med dator förstås.
    Bengt
  • Något har hänt. Radiotray avbryter som tidigare vid lite olika tidpunkter, ofta 16-20' in i programmet. Men nytt i veckan är att programmet inte tystnar som tidigare, utan kopplar över till live-strömning, i mitt fall hittills alltid p1, men det kanske har att göra med vad jag senast lyssnade på.
    håkan

Kommentera eller skriv ett nytt inlägg

Ditt inlägg & namn blir synligt för alla.
Din e-post visas aldrig publikt. Läs vår policy