我有一个应用程序，将录制和播放音频文件。一些音频文件正在使用HttpClient的使用简单的标准HTTP下载下载。它的工作像一个很长一段时间的魅力。现在，突然之间，我不能玩我下载的文件。它失败，这个堆栈。我存储在SD卡中的文件，我遇到问题都在手机上和USB连接的设备。

我已签了下载的文件在服务器上凉凉的，我可以发挥它没有任何问题。

以上是code片段我使用的（我知道recordingFile是文件的有效路径）。

  //活动类中    私人无效playRecording（）抛出IOException        文件recordingFile =新的文件（recordingFileName）;        的FileInputStream recordingInputStream =新的FileInputStream（recordingFile）;        audioMediaPlayer.playAudio（recordingInputStream）;    } 

下面是媒体播放器code：

  //它处理记录我的媒体播放器类中    公共无效playAudio（的FileInputStream的AudioInputStream）抛出IOException        mediaPlayer.reset（）;        mediaPlayer.setDataSource（audioInputStream.getFD（））;        媒体播放器prepare（）。        mediaPlayer.start（）;} 

下面是个例外：

  E / MediaPlayerService（555）：偏移误差E / MediaPlayer的（786）：无法创建媒体播放器W / System.err的（786）：java.io.IOException异常：setDataSourceFD失败：状态= 0x80000000的W / System.err的（786）：在android.media.MediaPlayer.setDataSource（本机方法）W / System.err的（786）：在android.media.MediaPlayer.setDataSource（MediaPlayer.java:632）W / System.err的（786）：在net.xxx.xxx.AudioMediaPlayer.playAudio（AudioMediaPlayer.java:69）W / System.err的（786）：在net.xxx.xxx.Downloads.playRecording（Downloads.java:299）W / System.err的（786）：在net.xxx.xxx.Downloads.access $ 0（Downloads.java:294）W / System.err的（786）：在net.xxx.xxx.Downloads $ 1.onClick（Downloads.java:135） 

我曾尝试寻求偏移误差的一些答案，但真不明白这是什么问题可能是。

PS我下载的文件与此code：

 公开的FileOutputStream executeHttpGet（FileOutputStream中的FileOutputStream）抛出ClientProtocolException，IOException异常{        尝试{            //执行HTTP POST请求            HTT presponse = httpClient.execute（httpPost，localContext）;            。INT状态= HTT presponse.getStatusLine（）的getStatus code（）;            //我们假设响应主体包含错误信息            如果（状态！= HttpStatus.SC_OK）{                ByteArrayOutputStream的ostream =新ByteArrayOutputStream（）;                HTT presponse.getEntity（）的writeTo（ostream的）。                的FileOutputStream = NULL;            }其他{                InputStream的内容= HTT presponse.getEntity（）的getContent（）。                字节[]缓冲区=新的字节[1024];                INT LEN = 0;                而（（LEN = content.read（缓冲液））大于0）{                    fileOutputStream.write（缓冲液，0，LEN）;                }                fileOutputStream.close（）;                content.close（）; //这也将关闭连接            }        }赶上（ClientProtocolException E1）{            // TODO自动生成catch块            e1.printStackTrace（）;            的FileOutputStream = NULL;        }赶上（IOException异常E2）{            // TODO自动生成catch块            e2.printStackTrace（）;            的FileOutputStream = NULL;        }        返回的FileOutputStream;    } 

解决方案

我解决它在我自己的。当我把它解决上面我的意见是这样的：

当我重构了code的一部分，我在一个哈希code我用它来允许下载，而不是做了一个错字。不幸的是我没有正确的捕捉，当我下载的文件强制文件是空的。基本上我，如果你尝试检索文件没有正确激活code发送一个错误的请求头。

罪魁祸首在这里：

 如果（状态！= HttpStatus.SC_OK）{            ByteArrayOutputStream的ostream =新ByteArrayOutputStream（）;            HTT presponse.getEntity（）的writeTo（ostream的）。            的FileOutputStream = NULL;        }其他{            InputStream的内容= HTT presponse.getEntity（）的getContent（）。            字节[]缓冲区=新的字节[1024];            INT LEN = 0;            而（（LEN = content.read（缓冲液））大于0）{                fileOutputStream.write（缓冲液，0，LEN）;            }            fileOutputStream.close（）;           content.close（）; //这也将关闭连接    } 

对于那些状态code回来一个坏（即坏的请求头被阻止的访问）的情况。我错过了捕捉空指针的情况下，并没有造成一个SQLite项自称的应用程序，下载成功，但尚未它是不会被更新。

教训：永远把在这些情况下，甚至为原型null检查。 ： - ）

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. :-)