MediaPlayer error -38???

Har lite problem med vissa mp3or som jag försöker streama via http.
Jag får nästan hela tiden ett error med felkoden -38 i min MediaPlayer.OnErrorListener.
Detta gäller dock bara vissa mp3or (kanske 30% av alla mina mp3or). Dock kan jag föra över dem till telefonen och spela dem utan problem och ibland fungerar de att streama dessutom.

Någon som har stött på något liknande?
Har hittat lite på nätet, men inga direkta lösningar eller ledtrådar över vad det kan vara

 

Låter som ett serverfel. Hur ser serversidan ut? Den som streamar.

 

Jag har tänkt lite i de banorna också, men det är en enkel webserver som levererar filen som den är och sätter lite headers (Content-Length och Content-Type).
Filerna fungerar dessutom utmärkt i alla browsers och mediaspelare som kan öppna http-streams.

Förenklat så ser det ut såhär på serversidan: http://code.google.com/p/musikcube/source/browse/trunk/src/core/http/TrackSender.cpp

 

Märker du någon skillnad om du kör över wifi eller 3g?

Har ingen aning om hur Android gör när man streamar musik, men har du någon kontroll över strömmarna? Blir det någon skillnad och du ökar upp buffertstorleken för din ström?

 

Vet inte vilka exempel du kollat på. Gör du något liknandes detta?
http://whyandroid.com/android/92-android-tutorial-3-custom-media-streaming-with-mediaplayer.html

 

Har tittat på denna typen av lösning tidigare, men det känns som om denna typen av lösning inte är riktigt stabil, plus att jag känner att jag inte vill mellanlagra någonting på telefonen som StreamingMediaPlayer gör.
I princip använder jag mig av MediaPlayern rakt av precis som i exemplet här:
http://developer.android.com/guide/topics/media/index.html#playfile
dvs:
* skapar MediaPlayern
* kör en setDataSource med en URL som input
* kör "prepare".. och det är här som den krashar med -38 i onError-metoden.

Mycket irriterande fel. Och efter en hel del googlande så verkar jag inte vara den enda med detta problem, och ingen verkar ha löst det
Börjar fundera på om jag inte ska skriva en encoder-plugin till servern som encodar om musiken till OGG-format när man streamar. OGG verkar vara det format som fungerar bäst på android, och då spelar det dessutom ingen roll om orginalfilen är ett format som android inte klarar av.

 

Nix! Samma resultat oavsett.
Tyvär har man väldigt liten kontroll över strömmarna och kan inte ställa in saker som bufferstorlek.

Tack för att du tog dig tid med lite input och förslag

 

Överhuvudtaget måste jag säja att hela MediaPlayer APIt är rätt så uselt på android.
* Man har ingen kontroll på streams.
* Man kan inte skriva egna implementeringar av streams (bara HTTP och RTSP).
* Ingen gapless playback stöd.
* Man har ingen access till audio i NDKt.
* mp3 encodern verkar vara lite skakig.

Ursäkta min klagosång, men ibland blir man lite frustrerad

 

Kan instämma i din klagosång. De har dessutom infört diverse buggar (som att SeekTo inte fungerar på strömmar ifrån 1.6 fastän det fungerade i 1.5).

Får du enbart -38 felet eller rapporteras några andra felkoder innan dess? Övriga felkoder som kan levereras kan du hitta information om här.

Är det någon skillnad i bitrate på de som fungerar respektive inte? VBR?

 

Det enda felet som jag får är "-38" när prepare körs. Har även provat med prepareAsync med samma resultat.
Kan inte heller se något konsekvent gällande formatet. Har ett antal CBR 192kbit som inte fungerar, liksom VBR-filer.
Föresten, coden ser ut såhär, och jag har provat att strukturera om den på ett antal sätt utan att lyckas få den att streama.
Mina teorier lutar mer och mer åt att jag gör något fel på serversidan som bara slår igenom ibland, men jag har jämfört outputten från min interna webserver med att göra samma sak från en apache-webserver med identiska resultat.


hmmm.. vänta nu...

 

Uppenbarligen så gör jag något fel.. mp3or som inte fungerar för mig fungerar utmärkt med meridian via apache-webservern.
Dock kan det ju vara så att meridian kör med tex StreamingMediaPlayer-classen eller liknande.

 

Det finns endel appar som klarar att spela diverse format som Android inte stödjer i sig.

Har du testat att köra WireShark på din dator och lyssna på "förhandlingen" mellan telefonen och webservern? Det kanske var det du menade när du skrev "jämförde outputten"?

 

Med "jämförde outputten" menade jag att jag gjorde en binär dump av exakt vad webservrarna svarade, men headers och allting.
Ska ta och testa wireshark och se om den gör på samma sätt.

Min fundering just nu är att min egna webserver kanske svarar för snabbt (hur nu det är möjligt). Om jag kör min egna webserver i debugmode så fungerar allting mycket bättre för det mesta.

 

Mycket underligt och som du säger så borde det inte vara möjligt att svara för snabbt. Testa med WireShark så ser du ju all trafik till och från datorn (inte bara de som når servern) med tider och headrar och se ifall paket tappas, skickas dubbelt m.m

 

Helt slut på idéer nu. Har även provat med wireshark och kan inte se någon skillnad.
Uppenbarligen är jag inte den enda med detta problem http://stackoverflow.com/questions/1965784/streaming-audio-from-a-url-in-android-using-mediaplayer

Frustrerad

 

Alltså, det var ju ruggigt länge sedan jag höll på med cpp. Men vad händer om du på serversidan ökar bufferten från 4kB (vilket är extremt litet för streaming media) till t.ex 32 eller 64 kB?

I din sendloop kan du ju även förenkla loopen till detta (på försök):

Kod:

while (!file->Eof() && !responder->Exited()){
   buffersize=file->Read(buffer,BUFFER_SIZE);
   responder->SendContent(buffer,buffersize);
}

Vet inte heller om du har buffrade strömmar, men det skulle jag använda (om det går).

Är du även helt säker på att Content-Type alltid är satt till något som är rätt, och är en char samma som en byte på din platform?

 

Bra idé. Jag hade lite sådana tankar häromdagen och testade istället att dra ner bufferstorleken (vet inte riktigt hur jag tänkte där ).
Content-Type ska alltid vara rätt, för annars kan inte filerna indexeras och läggas in i databasen överhuvudtaget.
Frågan är vad du menar med buffrade strömmar. Menar du att jag ska buffra fil-läsningen på servern före jag skickar?
En char är samma som en byte i detta fallet.

Återkommer med resultat senare idag

 

Nej, tänkte att när du skriver till en socket så blir du låst på skrivandet (om du använder synkron I/O) och icke buffrade strömmar. Om du har en buffrad ström så kommer du skriva till strömmen, och om bufferten inte är full retunera direkt, vilket gör att du kan börja läsa nästa "stycke" medans datat du just skrivit förs över till andra sidan. Om bufferten är full (andra sidan läser för långsamt) blir du dock hängandes på skrivandet.

Obs, detta är en förenkling för det finns även en tcp-buffer som är involverad.

 

Jag valde att göra som jag gjorde för att koden som skickar filen ändå kör i en egen tråd redan. Dessutom är delen som läser filen relativt försumbar eftersom operativsystemet automatiskt gör en readahead på filer som man öppnar, så merparten av tråden spenderas i skickandet ändå.
Valet av boost::asio för sockethantering är dock kanske illa valt eftersom det faktiskt är designat primärt för asynkron hantering

Provade föresten med en högre buffer (64k) utan någon förändring

 

Det var iof ett långskott. Tråkigt att det inte gjorde någon förändring. Min sista chansning är att -38 betyder något i stil med "buffer underrun", dvs att din klient inte hinner få data i samma takt som den spelar, och då skulle du behöva en större buffert på klientsidan för att öka chansen för att överleva.

Slutar låtarna alltid att fungera på samma ställe, eller varierar det?