I want to play mp3 file from server
server side code:
if (uri.contains("mp3")) {
FileInputStream fis = null;
try {
fis = new FileInputStream(audioFile.getAbsoluteFile());
} catch (FileNotFoundException e) {
e.printStackTrace();
}
return newFixedLengthResponse(Response.Status.OK, MIME_TYPES.get("mp3"), fis,audioFile.getTotalSpace());
}
while I am calling
192.168.0.7:XXXX/mp3
Error throw but played mp3 file in browser so why this error occure:
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:112)
at java.net.SocketOutputStream.write(SocketOutputStream.java:157)
at fi.iki.elonen.NanoHTTPD$Response.sendBody(NanoHTTPD.java:1694)
at fi.iki.elonen.NanoHTTPD$Response.sendBodyWithCorrectEncoding(NanoHTTPD.java:1667)
at fi.iki.elonen.NanoHTTPD$Response.sendBodyWithCorrectTransferAndEncoding(NanoHTTPD.java:1657)
at fi.iki.elonen.NanoHTTPD$Response.send(NanoHTTPD.java:1624)
at fi.iki.elonen.NanoHTTPD$HTTPSession.execute(NanoHTTPD.java:957)
at fi.iki.elonen.NanoHTTPD$ClientHandler.run(NanoHTTPD.java:192)
at java.lang.Thread.run(Thread.java:761)
Broken pipe usually happen when someone (here the server) is trying to write in a socket that was closed on the other side (here the client).
You should probably use length() (size of the file) instead of getTotalSpace() (size of the partition)
You could also try to use a chunked response:
return newChunkedResponse(Response.Status.OK, MIME_TYPES.get("mp3"), fis);
Related
UPDATE:
I found this post, which details exactly the same problem I am seeing. It turns out that the fact I am using a Pipe approach in my DocumentsProvider to stream content from DropBox means that ExoPlayer doesn't know the size of the file ahead of time, and so by default was not saving it to the cache.
So I ended up doing what I presume the author did - I created a custom CacheDataSource for these situations that alters the DataSpec.flags variable in the open() method of that class:
public long open(DataSpec dataSpec) throws IOException {
try {
key = cacheKeyFactory.buildCacheKey(dataSpec);
uri = dataSpec.uri;
actualUri = getRedirectedUriOrDefault(cache, key, /* defaultUri= */ uri);
httpMethod = dataSpec.httpMethod;
if ( !dataSpec.isFlagSet(DataSpec.FLAG_ALLOW_CACHING_UNKNOWN_LENGTH) ) { // <-- update here
flags = (dataSpec.flags | DataSpec.FLAG_ALLOW_CACHING_UNKNOWN_LENGTH);
} else {
flags = dataSpec.flags;
}
readPosition = dataSpec.position;
Not the optimum solution, and I also chimed in on the other post with a request for a more supported way to indicate this flag should be set.
But at least now my streamed files are being saved in the cache.
I am implementing a customer CacheDataSourceFactory for ExoPlayer2, in order to implement a cache to store videos streamed to ExoPlayer.
I have reviewed several posts here, this one was helpful in getting the general approach right to have a video cached into the directory of my choice.
I noticed that when handling a URI that resolves to my custom DocumentsProvider, the Cache defined by the CacheDataSourceFactory is only used to store what looks like a "pointer" or "index" file ("cached_content_index.exi"). Looking in that file I see the URI of the video streamed by my custom DocumentsProvider. However the actual video is not in the cache.
Here is the relevant portion of my Provider, it's quite straight forward:
// Return a descriptor that will stream the file
Timber.d("In openDocument of DropboxProvider for Id: %s, streaming from source", documentId);
ParcelFileDescriptor[] pipe;
try {
pipe = ParcelFileDescriptor.createPipe();
// Get input stream for the pipe
DbxDownloader downloader = mDbxClient.files().download(fileMetadata.getPathLower(), fileMetadata.getRev());
new TransferThread(downloader.getInputStream(), new ParcelFileDescriptor.AutoCloseOutputStream(pipe[1]), signal, fileMetadata.getSize()).start();
return pipe[0];
} catch (DbxException dbe) {
Timber.d("Got IDbxException when streaming content: %s", dbe.getMessage());
} catch (IOException ioe) {
Timber.d("Got IOException when streaming content: %s", ioe.getMessage());
} catch (Exception e) {
Timber.d("Got Exception when streaming content: %s", e.getMessage());
}
return null;
And the TransferThread:
private static class TransferThread extends Thread {
final InputStream in;
final OutputStream out;
final CancellationSignal signal;
final long size;
TransferThread(InputStream in, OutputStream out, CancellationSignal signal, long size) {
this.in = in;
this.out = out;
this.signal = signal;
this.size = size;
}
#Override
public void run() {
int biteSize = (8*1024);
if ( size <= (biteSize * 8) ) {
biteSize = Math.max( ((int)(size / (biteSize*2))) * (biteSize * 2), biteSize);
}
Timber.d("TransferThread: File size is: %s, buffer biteSize set to: %d", InTouchUtils.getFormattedFileSize(size), biteSize);
byte[] buf = new byte[biteSize];
int len;
try {
while ( ((len=in.read(buf)) >= 0) && (signal == null || !signal.isCanceled()) ) {
out.write(buf, 0, len);
}
} catch (IOException e) {
// When Glide is used to request a URI where this provider resolves the query,
// it will close the stream out from under us once it has fetched enough bytes
// to render a single frame as an image if the if it is to a video, so
// we swallow that exception here, only logging the error if it isn't that EPIPE
// (broken pipe due to one end being closed) exception.
if ( !(e.getMessage().contains("EPIPE"))) {
Timber.d("TransferThread: Got IOException transferring file: %s", e.getMessage());
}
} finally {
try {
if (in != null) {
in.close();
}
if ( out != null ) {
out.flush();
out.close();
}
Timber.d("TransferThread: Finished streaming file.");
} catch (IOException ioe) {
Timber.d("TransferThread: Got IOException closing file: %s", ioe.getMessage());
}
}
}
}
Again - ExoPlayer seems quite happy with the ParcelFileDescriptor it receives from the DocumentsProvider in this case - it takes the bytes streamed to it and plays the video. I am just not seeing the video file end up in the cache.
I also tried an example streaming a video from my Google Drive (which uses the out-of-the-box documents provider from the SAF), and this time the video did wind up in the cache.
Since they both use the same MediaSource instance - there must be an approach that the Google Docs provider takes so that ExoPlayer knows to place the resulting streamed video in the cache that my custom Dropbox DocumentsProvider is not doing.
Does anyone know how to get to the source code of the DocumentsProvider that ships with the SAF that manages access to Google Docs? I'd like to see what it is doing in its openDocument() method.
Is the fact that the Dropbox provider is utilizing a Pipe in its ParcelFileDescriptor something that ExoPlayer doesn't handle?
Other Ideas?
I'm testing libstreaming on new Android Lollipop, and this code that worked on previous release, seems to launch exception.
try {
mMediaRecorder = new MediaRecorder();
mMediaRecorder.setCamera(mCamera);
mMediaRecorder.setVideoSource(MediaRecorder.VideoSource.CAMERA);
mMediaRecorder.setOutputFormat(MediaRecorder.OutputFormat.THREE_GPP);
mMediaRecorder.setVideoEncoder(mVideoEncoder);
mMediaRecorder.setPreviewDisplay(mSurfaceView.getHolder().getSurface());
mMediaRecorder.setVideoSize(mRequestedQuality.resX,mRequestedQuality.resY);
mMediaRecorder.setVideoFrameRate(mRequestedQuality.framerate);
// The bandwidth actually consumed is often above what was requested
mMediaRecorder.setVideoEncodingBitRate((int)(mRequestedQuality.bitrate*0.8));
// We write the ouput of the camera in a local socket instead of a file !
// This one little trick makes streaming feasible quiet simply: data from the camera
// can then be manipulated at the other end of the socket
mMediaRecorder.setOutputFile(mSender.getFileDescriptor());
mMediaRecorder.prepare();
mMediaRecorder.start();
} catch (Exception e) {
throw new ConfNotSupportedException(e.getMessage());
}
Launched exception is:
MediaRecorder: start failed -38
11-18 09:50:21.028: W/System.err(15783): net.majorkernelpanic.streaming.exceptions.ConfNotSupportedException
11-18 09:50:21.028: W/System.err(15783): at net.majorkernelpanic.streaming.video.VideoStream.encodeWithMediaRecorder(VideoStream.java:442)
11-18 09:50:21.028: W/System.err(15783): at net.majorkernelpanic.streaming.MediaStream.start(MediaStream.java:250)
I've tried to comment:
mMediaRecorder.setOutputFile(mSender.getFileDescriptor());
no exception launched, but when I start streaming a dialog tell me that need an outputfile.
Help appreciated.
I filed a bug report on AOSP.
https://code.google.com/p/android/issues/detail?id=80715
"The current SELinux policies don't allow for mediaserver to handle app generated abstract unix domain sockets.
Instead, I'd recommend you create a pipe-pair ( http://developer.android.com/reference/android/os/ParcelFileDescriptor.html#createPipe() ) which is allowed by the Android 5.0 policy.
"
I don't know why they did this or how we were supposed to know.
I'm using a very old/modified (can't tell) version of libstreaming where mediastream is still extended from mediarecorder, but looking at the current version, in MediaStream you'll probably want to change createSockets to something including the following:
ParcelFileDescriptor[] parcelFileDescriptors =ParcelFileDescriptor.createPipe();
parcelRead = new ParcelFileDescriptor(parcelFileDescriptors[0]);
parcelWrite = new ParcelFileDescriptor(parcelFileDescriptors[1]);
then in your video/audio stream
setOutputFile(parcelWrite.getFileDescriptor());
and in that same file
change
// The packetizer encapsulates the bit stream in an RTP stream and send it over the network
mPacketizer.setInputStream(mReceiver.getInputStream());
mPacketizer.start();
to
InputStream is = null;
try{ is = new ParcelFileDescriptor.AutoCloseInputStream(parcelRead);
}
catch (Exception e){}
mPacketizer.setInputStream(is);
As andreasperelli pointed out in the comment, make sure to close the ParcelFileDescriptors in closeSockets(), or depending on your implementation and version, before closeSockets() and before you call MediaRecorder.stop().
at Android 6.0 I resolve this problem with the code
new Thread(new Runnable() {
#Override public void run() {
FileInputStream inputStream = null;
try {
inputStream = new FileInputStream(path);
} catch (FileNotFoundException e) {
e.printStackTrace();
}
while (true) {
byte[] buffer = new byte[0];
try {
buffer = new byte[inputStream.available()];
} catch (IOException e) {
e.printStackTrace();
}
try {
inputStream.read(buffer);
} catch (IOException e) {
e.printStackTrace();
}
try {
mSender.getOutputStream().write(buffer);
mSender.getOutputStream().flush();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}).start();
I use a file as buffer and write bytes at another thread.the MediaRecorder output to the file.
I'm working on an application which supposed to run on devices from API 8 to latest.
Actually I'm dealing with Mediaplayer. the code is in a fragment and is simply:
MediaPlayer mediaPlayer = null;
if (mediaPlayer = MediaPlayer.create(getActivity(), myAudioFileUri) != null) {
. . .
}
This code perfectly works on Android 4.4.2, MediaPlayer.create() returns a valid value and I can use Mediaplayer without problem.
Unfortunately, MediaPlayer.create() returns null on Android 2.3.7.
this is my problem and I didn't find on Internet a reason why it could cause problem this Android version neither a difference in the way to use it.
Both tests have benn done on GenyMotion emulator as I don't have such an old Android device.
Edit:
So I verified using the shell adb that the problem really comes from mp3 file permissions if I "chmod 777 myfile.mp3", I can succesfully read it.
My problem now is to know how to change permissions on Android 2.3
The code used to download the file from my remote server to copy it locally is the next one:
private Uri downloadFileFromURL(URL url, String fileName) {
try {
URLConnection conn = url.openConnection();
HttpURLConnection httpConnection = conn instanceof HttpURLConnection ? (HttpURLConnection ) conn : null;
int responseCode = httpConnection.getResponseCode();
if (responseCode == HttpURLConnection.HTTP_OK){
int len, length = 0;
byte[] buf = new byte[8192];
InputStream is = httpConnection.getInputStream();
File file = new File(getActivity().getApplicationContext().getFilesDir().getParentFile().getPath(), fileName);
OutputStream os = new FileOutputStream(file);
try {
while((len = is.read(buf, 0, buf.length)) > 0) {
os.write(buf, 0, len);
length += len;
}
os.flush();
}
finally {
is.close();
os.close();
}
String chmodString = "chmod 777 " + getActivity().getApplicationContext().getFilesDir().getParentFile().getPath() +"/" + fileName;
Process sh = Runtime.getRuntime().exec("su", null, new File("/system/bin/"));
OutputStream osChgPerms = sh.getOutputStream();
osChgPerms.write((chmodString).getBytes("ASCII"));
osChgPerms.flush();
osChgPerms.close();
try {
sh.waitFor();
} catch (InterruptedException e) {
Log.d("2ndGuide", "InterruptedException." + e);
}
return Uri.fromFile(file);
}
}
catch(IOException e)
{
Log.d("2ndGuide", "IO Exception." + e);
}
return null;
}
But osChgPerms.write((chmodString).getBytes("ASCII")); generates an IOException: broken pipe.
I suppose I didn't understand how to execute the command.
What's wrong?
Regards,
I can point you 2 possible reasons behind that, not sure whether they can solve your issue.
Android can only allocate a certain amount of MediaPlayer objects, you need to release any MediaPlayer object by using mediaPlayer.release().
Android supports only 8- and 16-bit linear PCM, so check you audio
file. More: Supported Media Formats
So in fact the problem clearly comes from the fact that the media files must be readable for everybody to be readable by the media player.
This behaviour only occurs on pre HONEYCOMB devices.
From my Android app I try to download from the windows Azure blob storage using the following URL: http://iclyps.blob.core.windows.net/broadcasts/23_6.mp4
The resulting file is corrupt when I download it from within my app. Same error occurs when I download it using the default Browser or Chrome. Also from the Easy Downloader app, the same error occurs. Only a download from my PC or using Firefox Beta from the Android device (or emulator), the file is retrieved correctly.
I use the following code (snippet):
try {
HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection();
//set up some things on the connection
urlConnection.setRequestMethod("GET");
urlConnection.setDoOutput(true);
//and connect!
urlConnection.connect();
bis = new BufferedInputStream(urlConnection.getInputStream(), BUFSIZE);
bos = new BufferedOutputStream(
context.openFileOutput(TMPFILE, Context.MODE_PRIVATE), BUFSIZE);
/*
* Read bytes to the buffer in chunks of BUFSIZE bytes until there is nothing more to read.
* Each chunk is written to the output file.
*/
byte[] buf = new byte[BUFSIZE];
int nBytes = 0;
int tBytes = 0;
while ((nBytes = bis.read(buf, 0, BUFSIZE)) > 0) {
bos.write(buf, 0, nBytes);
tBytes += nBytes;
}
if (tBytes == 0) throw new Exception("no bytes received");
bos.flush();
MobyLog.d(TAG, "download succeeded: #bytes = " + Integer.toString(tBytes));
return true;
} catch (Exception e) {
MobyLog.e(TAG, "download failed: " + e);
context.deleteFile(TMPFILE); // remove possibly present partial file.
return false;
} finally {
if (bis != null) try { bis.close(); } catch (IOException e) {MobyLog.e(TAG, "bis close exception: " + e); };
if (bos != null) try { bos.close(); } catch (IOException e) {MobyLog.e(TAG, "bos close exception: " + e); };
}
Analyzing the files shows that the first part (about 700K) of the original file is repeated a number of times in the corrupted files, resulting in an invalid mp4 file.
Putting the file on another webserver (Apache/IIS), and downloading the file from that location does result in a correct download.
Has anyone experienced a similar problem performing a download from Azure? Can someone provide a solution?
Cheers,
Harald...
Have you tried using the azure-sdk-for-java in your android app?
Our scenario is slightly different in that we using the sdk to pull and push images from blob storage to a custom android app. But the fundamentals should be the same.
I have an application that will record and play audio files. Some of the audio files are downloaded using simple standard http downloads using httpclient. It worked like a charm for a long time. Now all of a sudden I cannot play the files I download. It fails with this stack. I store the files on the SDCard and I experience the problem both on a handset and a USB connected device.
I have checked that the downloaded file is cool on the server, and I can play it without any issues.
These are the code snippets I use ( I know that recordingFile is a valid path for the file).
// inside the activity class
private void playRecording() throws IOException{
File recordingFile = new File(recordingFileName);
FileInputStream recordingInputStream = new FileInputStream(recordingFile);
audioMediaPlayer.playAudio(recordingInputStream);
}
Here is the media player code:
// inside my media player class which handles the recordings
public void playAudio(FileInputStream audioInputStream) throws IOException {
mediaPlayer.reset();
mediaPlayer.setDataSource(audioInputStream.getFD());
mediaPlayer.prepare();
mediaPlayer.start();
}
Here is the exception:
E/MediaPlayerService( 555): offset error
E/MediaPlayer( 786): Unable to to create media player
W/System.err( 786): java.io.IOException: setDataSourceFD failed.: status=0x80000000
W/System.err( 786): at android.media.MediaPlayer.setDataSource(Native Method)
W/System.err( 786): at android.media.MediaPlayer.setDataSource(MediaPlayer.java:632)
W/System.err( 786): at net.xxx.xxx.AudioMediaPlayer.playAudio(AudioMediaPlayer.java:69)
W/System.err( 786): at net.xxx.xxx.Downloads.playRecording(Downloads.java:299)
W/System.err( 786): at net.xxx.xxx.Downloads.access$0(Downloads.java:294)
W/System.err( 786): at net.xxx.xxx.Downloads$1.onClick(Downloads.java:135)
I have tried seeking some answer of the offset error, but not really clear what this issue might be.
PS I download the file with this code:
public FileOutputStream executeHttpGet(FileOutputStream fileOutputStream) throws ClientProtocolException, IOException{
try {
// Execute HTTP Post Request
httpResponse = httpClient.execute(httpPost, localContext);
int status = httpResponse.getStatusLine().getStatusCode();
// we assume that the response body contains the error message
if (status != HttpStatus.SC_OK) {
ByteArrayOutputStream ostream = new ByteArrayOutputStream();
httpResponse.getEntity().writeTo(ostream);
fileOutputStream = null;
} else {
InputStream content = httpResponse.getEntity().getContent();
byte[] buffer = new byte[1024];
int len = 0;
while ( (len = content.read(buffer)) > 0 ) {
fileOutputStream.write(buffer,0, len);
}
fileOutputStream.close();
content.close(); // this will also close the connection
}
} catch (ClientProtocolException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
fileOutputStream = null;
} catch (IOException e2) {
// TODO Auto-generated catch block
e2.printStackTrace();
fileOutputStream = null;
}
return fileOutputStream;
}
I solved it on my own. As I put it my comment above the solution was this:
When I refactored part of the code I made a typo on a hash code I use to allow downloads and not. Unfortunately I didn't have the proper catch when I downloaded the file forcing the file to be empty. Basically I send a bad request header if you try to retrieve a file without a proper activation code.
The culprit was here:
if (status != HttpStatus.SC_OK) {
ByteArrayOutputStream ostream = new ByteArrayOutputStream();
httpResponse.getEntity().writeTo(ostream);
fileOutputStream = null;
} else {
InputStream content = httpResponse.getEntity().getContent();
byte[] buffer = new byte[1024];
int len = 0;
while ( (len = content.read(buffer)) > 0 ) {
fileOutputStream.write(buffer,0, len);
}
fileOutputStream.close();
content.close(); // this will also close the connection
}
For cases where the status code came back a as bad (i.e. bad request header for blocked accesses). What I missed was to capture the case of a null pointer there and that caused a SQLite entry to be updated claiming to the app that the download was successful but yet it wasn't.
Lesson learnt: Always put in the null checks for these cases even for prototypes. :-)
First, make sure your device is not mounted. Either Android or the host PC can access the SD card, but not both simultaneously.
Second, it is unclear why you are using a FileInputStream and getFD(). Just pass the path to the file on the SD card to the MediaPlayer (e.g., new File(Environment.getExternalStorageDirectory(), "yourfile.mp3")) and let the player open the file.