I've finished developing a game, but it's very annoying that sometimes (yes, only sometimes!) when I open it, it fails, and I can see in logcat this error: java.io.IOException: Prepare failed.: status=0x80000000.
It's very weird because it's a local file (2MB mp3 file), and I don't know why it shows a IOException. And only sometimes, not always...
EDIT: It seems that is related with proguard, because it only happens with release version...
I finally solved it.
It happened because my MediaPlayer variables were static, so when I restart the app I was creating more MediaPlayers without releasing previous ones, and there is a limit of 8 (at least in Android 2.3.6, where I tested it). Calling mediaPlayer.release() (if mediaPlayer != null, of course) it's solved.
Hope it helps someone.
I have get the same issue here. (may 2021)
And when I find on internet I see some answer about this thing. They said that when mediaPlayer prepare datasource and it can not read the end char so it return IOException Prepare failed. So the way they resolved that is convert to new file with difference type (wav, mp4, mp3,...). Hope can help anyone on this issue.
Related
Android 11 introduced multiple changes to file storage and access. Apparently one of them is that one can no longer target output to '/dev/null' (my scenario is actually exactly explained in this old question).
Although the cited question solved the particular issue, one thing remains unanswered: what is Android 11's equivalent to '/dev/null'. That is, if one does not need the output of a particular operation (and in our case it is an operation that creates a biggish file).
Eventually I ended up solving my problem the following way (answer tailored to MediaRecorder problem but can be generalized to other situations too):
fun MediaRecorder.setOutputFile(context: Context) {
val tmpRecordingFolder = File(context.filesDir, "tmp_media")
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
setOutputFile(File(tmpRecordingFolder, "recording.mp3"))
} else {
setOutputFile("/dev/null")
}
}
Basically I am setting the output to be in the internal storage. I hope the file will not get huge and I am deleting the file in as many places in the code as possible. This seems to work on newer devices, currently have not yet ran into storage problems either, but the solution is not rolled out to production yet. Will update my answer if problems are identified.
I had the same issue, you'll have to specify a path since MediaRecorder crashes in Android 11 if you don't provide it, in order to avoid writing a massive file you could try to flush the file by stopping / restarting MediaRecorder, I been dealing with this issue for a few days too.
I replied a more detailed answer here: MediaRecorder Android 11 start failed -1004
I have a videoView and loading video's from a remote server.
I'm getting random error as per below.
Problem is, it works sometimes and sometimes it doesn't.
videoView.setVideoURI(Uri.parse(Constants.API_IMAGE_HOST + "ads/video/" + this.adVideoObject.ad_videos_id + ".mp4"));
the error i get is:
MediaPlayer﹕ setDataSource IOException happend :
java.io.FileNotFoundException: No content provider:
Again, I get it sometimes but not always.
Ok, as I have mentioned in numerous other posts about VideoView, DONT USE IT! I am a professional Android developer that develops apps that are all about video playback and in my experience, VideoView is entirely unreliable and is very difficult if not impossible to get it to behave correctly across multiple devices. I would strongly suggest for you to look into the ExoPlayer library if playback is at all important to your app. It is harder to setup but the performance and reliability improvements are soo worth it.
I apologize that this does not explicitly answer your question. However I believe that you will find the ExoPlayer library a pure joy to work with over VideoView or MediaPlayer.
The error
D/MediaPlayer: setDataSource IOException | SecurityException happend :
java.io.FileNotFoundException: No content provider: http://192.168.1.114:1376/%25/F885C5CE27F16C4D64588D48A3001A1B/9.mp4
at android.content.ContentResolver.openTypedAssetFileDescriptor(ContentResolver.java:1137)
at android.content.ContentResolver.openAssetFileDescriptor(ContentResolver.java:988)
at android.content.ContentResolver.openAssetFileDescriptor(ContentResolver.java:911)
at android.media.MediaPlayer.attemptDataSource(MediaPlayer.java:1102)
at android.media.MediaPlayer.setDataSource(MediaPlayer.java:1093)
Is part of the normal flow of the VideoView setDataSource. It tries to open the file locally, and then moves onto loading remotely.
Typically there will be a further error message which explains the actual failure.
In my case, it was getDuration being called in the incorrect state. So look further down the logs, and check that you are following the state diagram in the documents and ensuring that the API is called only when the view is in the correct state
I have to implement a GStreamer pipeline on Android which will get a live mpegts stream from a mpegts server on a linux machine(also implemented through GStreamer).
Now, I have a Samdung Galaxy Tab2, 5113, which has Android-4.1.2-JellyBean and API level=16
My receiver pipeline is as follows:
data->pipeline = gst_parse_launch("udpsrc caps=\"video/mpegts, systemstream=true, packet-size=188\" ! tsdemux ! queue ! h264parse ! amcviddec-omxgoogleh264decoder ! eglglessink", &error);
This as per Android-Tutorial-3 of GStreamerSDK.
When I press the play button,
I get this error:
06-26 00:04:56.927: D/GStreamer+tutorial-3(7201): 0:00:05.920807000 0x5a65c320 jni/tutorial-3.c:88:set_ui_message Setting message to: Error received from element amcvideodec-omxgoogleh264decoder0: GStreamer encountered a general supporting library error.
A more detailed log of the application as shown on the logcat of the Eclipse IDE:http://pastebin.com/EX8sgcEp
So it seems that the amcviddec-omxgoogleh264decoder element cannot dequeue the input data as well as GStreamer encounters a library error.
I would appreciate any help or suggestions.
We had solved the problem some time back.
Just putting it here for any body else's reference.
The problem was, if we are to use amcviddec-omxgoogleh264decoder, there are some dependent files which need to be installed besides the gstreamer application. Don't knopw exactly what they were.
Anyways, if one sees the /etc/media-codec.xml file in the android root, we will get to know all the multimedia codecs supported by one's android device. This includes the codec supported by hardware codec chips also.
For us, we tried the amcviddec-omxtiducati1videodecoder, and it worked like a charm.
Regards,
Yusuf Husainy.
I am working on an android project which needs to create and write files rapidly. I am using ndk for this purpose and found that fopen() call takes uncertain amount of time, from minimum ~30ms to several seconds whening running from the main thread. After opening the file, I then need to compute some results, store results into the opened file and then close it.
I am trying to put it into another thread but not sure if it helps at all and how to handle scheduling issue if it does. I am also thinking about possibly opening many of those file descriptors at the beginning of the application and maintain a pool of those through the applcation. Anyone helping to point to the right direction?
It sounds like you are trying to go very low level.
Have you considered using the open() write() and close() System calls. The c-library fopen calls do some nice things for you such as buffering, but the system calls are likely to be faster. You will have to profile, but I think you will see lower latency.
int fd = open("myfilepath",O_WRONLY|O_CREAT);
write(fd,myData, myDataSize);
close(fd);
You will find more info here.
http://www.tutorialspoint.com/unix_system_calls/open.htm
I made an Android Applicatiob to upload videos to my server, it's working fine but if the file bigger than 21MB it's forced close.
so i think it's a memory issue, i tried to use setFixedLengthStreamingMode method
conn.setFixedLengthStreamingMode((int) new File(existingFileName).length());
but it's not working at all with the small & big files.
I passed the value to the Log to make sure it the file size in bytes and that is correct but the method not working
I tried to convert the connection to chunk mode by using this line
conn.setChunkedStreamingMode(100);
but also this line makes the Application fails
so I don't know what to do
Probably you are loading entire file into memory. This link may be helpful to cater your problem https://stackoverflow.com/a/9630475/830945