I have a problem with GoogleWrapperSample for OpenSteetMap (I use osmdroid latest jar - 3.0.8). It is compiling fine, but the emulator (Google API 2.2 device) throws a toast with "Activity is not responding" message and nothing else. There are no errors/warnings and as it is a logger in osmdroid classes I can only receive some logging information. LogCat gives something like this:
02-14 13:21:20.246: W/System.err(968): 38 [main] INFO org.osmdroid.views.MapView - Using tile source: org.osmdroid.tileprovider.tilesource.XYTileSource#44eb5260
02-14 13:21:20.316: W/System.err(968): 113 [main] INFO org.osmdroid.tileprovider.modules.MapTileFileStorageProviderBase - sdcard state: mounted
02-14 13:21:20.336: W/System.err(968): 129 [main] INFO org.osmdroid.tileprovider.modules.MapTileFileStorageProviderBase - sdcard state: mounted
02-14 13:21:30.166: I/dalvikvm(968): threadid=3: reacting to signal 3
02-14 13:21:30.207: I/dalvikvm(968): Wrote stack traces to '/data/anr/traces.txt'
Has anyone got this sample working? I have no ideas how to solve this problem.
Maybe, it is somehow connected with getting OSM tiles via network or something like that - we have a proxy connection so https and SSL port are not available (but all in all network on the device is ok).
UPD.
On HTC Desire it works properly but OSM map is not available - there is only a grid. On the other hand, Google map is ok.
LogCat contains this:
02-15 14:47:00.074: W/System.err(2106): 6 [main] INFO org.osmdroid.views.MapView - Using tile source: org.osmdroid.tileprovider.tilesource.XYTileSource#46361618
02-15 14:47:00.084: W/System.err(2106): 23 [main] INFO org.osmdroid.tileprovider.modules.MapTileFileStorageProviderBase - sdcard state: mounted
02-15 14:47:00.094: W/System.err(2106): 26 [main] INFO org.osmdroid.tileprovider.modules.MapTileFileStorageProviderBase - sdcard state: mounted
02-15 14:47:00.184: D/dalvikvm(2106): GC_FOR_MALLOC freed 4349 objects / 315536 bytes in 33ms
02-15 14:47:00.214: D/dalvikvm(2106): GC_EXTERNAL_ALLOC freed 317 objects / 14952 bytes in 28ms
02-15 14:47:00.224: W/System.err(2106): 160 [main] INFO org.osmdroid.tileprovider.MapTileProviderBase - rescale tile cache from 0 to 14
02-15 14:47:00.234: W/System.err(2106): 170 [main] INFO org.osmdroid.tileprovider.MapTileProviderBase - Finished rescale in 10ms
02-15 14:47:00.284: I/MapActivity(2106): Handling network change notification:CONNECTED
02-15 14:47:00.284: E/MapActivity(2106): Couldn't get connection factory client
On emulator there is no progress.
I think that "Couldn't get connection factory client" is the reason of my problem but have no idea about the way to fix this.
There are two situations where an Application Not Responding (ANR) may occur:
No response to an input event (e.g. key press, screen touch) within 5 seconds.
A BroadcastReceiver hasn't finished executing within 10 seconds.
Common causes of an ANR are (stalled) networking operations or expensive calculations.
There are a number of posts on SO on how to solve it (e.g. here or here), but the biggest help is probably the Android API.
I took a quick look at the sample code, I'm not sure but perhaps the setMapView() method that is called in onResume() takes too long. You may be able to test this by commenting that line out. Otherwise, check the traces.txt file on the emulator for clues and/or add logging statements to your code to pinpoint which operation is taking too long.
As for your "Couldn't get connection factory client" error, that question has already been answered here
Related
My app worked fine at api29. Now getting this native error. No clue otherwise.
D/TransportRuntime.SQLiteEventStore: Storing event with priority=DEFAULT, name=FIREPERF for destination cct
V/FA: Connection attempt already in progress
V/FA: Connection attempt already in progress
D/TransportRuntime.JobInfoScheduler: Scheduling upload for context TransportContext(cct, DEFAULT, MSRodHRwczovL2ZpcmViYXNlbG9nZ2luZy1wYS5nb29nbGVhcGlzLmNvbS92MS9maXJlbG9nL2xlZ2FjeS9iYXRjaGxvZ1xBSXphU3lDY2traUg4aTJaQVJ3T3MxTEV6RktsZDE1YU9HOG96S28=) with jobId=-546033166 in 30000ms(Backend next call timestamp 1639520060629). Attempt 1
D/mainact: buildDisplayDataBase:
A/libc: fdsan: attempted to close file descriptor 75, expected to be unowned, actually owned by FILE* 0xf108246c
Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 20661 (eymoreau.fitlog), pid 20661 (eymoreau.fitlog)
Disconnected from the target VM, address: 'localhost:60917', transport: 'socket'
If you are displaying images try eliminating them to see of it fixes the error.
It did for me and I ended up changing my image loading from:
mainMenu_viewHolder.getImageView().setImageResource(R.drawable.gear);
to...
Bitmap checkImg = BitmapFactory.decodeResource(fragment.getResources(), R.drawable.check);
mainMenu_viewHolder.getImageView().setImageBitmap(checkImg);
The issue is buried very deep so if this doesn't work for you don't try stepping through your code or researching the native error. It will be wasted time. Just disable your fragments entire view structure and add back in piece by piece.
I have a neo4j 3.2.1 multi-labeled multi-properties graph database which has 4M nodes, 15M edges, and 4.8M distinct labels with ~6GB size on the disk.
I've imported the dataset using "neo4j-import" tool using a linux machine.
I can open the dataset, traverse the nodes, edges, and their descriptions well using the Java API. However, once I want to shut it down, it takes a lot of time and finally, it gives me the following log file error:
2017-08-04 07:07:38.189+0000 INFO [o.n.k.i.f.GraphDatabaseFacadeFactory] Shutdown started
2017-08-04 07:07:38.190+0000 INFO [o.n.k.i.f.GraphDatabaseFacadeFactory] Database is now unavailable
2017-08-04 07:07:38.198+0000 INFO [o.n.k.i.t.l.c.CheckPointerImpl] Check Pointing triggered by database shutdown [5399]: Starting check pointing...
2017-08-04 07:07:38.198+0000 INFO [o.n.k.i.t.l.c.CheckPointerImpl] Check Pointing triggered by database shutdown [5399]: Starting store flush...
2017-08-04 07:23:35.022+0000 ERROR [o.n.k.i.t.l.c.CheckPointerImpl] Error performing check point Failed to rotate logs. Expected version: 5399, actual version: 5274, wait timeout (ms): 956815
org.neo4j.kernel.impl.store.kvstore.RotationTimeoutException: Failed to rotate logs. Expected version: 5399, actual version: 5274, wait timeout (ms): 956815
at org.neo4j.kernel.impl.store.kvstore.RotationState$Rotation.rotate(RotationState.java:79)
at org.neo4j.kernel.impl.store.kvstore.RotationState$Rotation.rotate(RotationState.java:52)
at org.neo4j.kernel.impl.store.kvstore.AbstractKeyValueStore$RotationTask.rotate(AbstractKeyValueStore.java:311)
at org.neo4j.kernel.impl.store.kvstore.AbstractKeyValueStore$RotationTask.rotate(AbstractKeyValueStore.java:288)
at org.neo4j.kernel.impl.store.counts.CountsTracker.rotate(CountsTracker.java:154)
at org.neo4j.kernel.impl.store.NeoStores.flush(NeoStores.java:242)
at org.neo4j.kernel.impl.storageengine.impl.recordstorage.RecordStorageEngine.flushAndForce(RecordStorageEngine.java:480)
at org.neo4j.kernel.impl.transaction.log.checkpoint.CheckPointerImpl.doCheckPoint(CheckPointerImpl.java:160)
at org.neo4j.kernel.impl.transaction.log.checkpoint.CheckPointerImpl.forceCheckPoint(CheckPointerImpl.java:88)
at org.neo4j.kernel.NeoStoreDataSource$3.shutdown(NeoStoreDataSource.java:794)
at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.shutdown(LifeSupport.java:489)
at org.neo4j.kernel.lifecycle.LifeSupport.shutdown(LifeSupport.java:206)
at org.neo4j.kernel.NeoStoreDataSource.stop(NeoStoreDataSource.java:766)
at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.stop(LifeSupport.java:458)
at org.neo4j.kernel.lifecycle.LifeSupport.stopInstances(LifeSupport.java:161)
at org.neo4j.kernel.lifecycle.LifeSupport.stop(LifeSupport.java:143)
at org.neo4j.kernel.impl.transaction.state.DataSourceManager.stop(DataSourceManager.java:120)
at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.stop(LifeSupport.java:458)
at org.neo4j.kernel.lifecycle.LifeSupport.stopInstances(LifeSupport.java:161)
at org.neo4j.kernel.lifecycle.LifeSupport.stop(LifeSupport.java:143)
at org.neo4j.kernel.lifecycle.LifeSupport.shutdown(LifeSupport.java:191)
at org.neo4j.kernel.impl.factory.ClassicCoreSPI.shutdown(ClassicCoreSPI.java:159)
at org.neo4j.kernel.impl.factory.GraphDatabaseFacade.shutdown(GraphDatabaseFacade.java:366)
at experiment.caseStudy.TestDatasetHealth.run(TestDatasetHealth.java:70)
at experiment.caseStudy.TestDatasetHealth.main(TestDatasetHealth.java:29)
2017-08-04 07:23:35.665+0000 INFO [o.n.k.i.DiagnosticsManager] --- STOPPING diagnostics START ---
2017-08-04 07:23:35.666+0000 INFO [o.n.k.i.DiagnosticsManager] --- STOPPING diagnostics END ---
In the Java itself, I get the following exception:
Exception in thread "main" org.neo4j.kernel.lifecycle.LifecycleException: Component 'org.neo4j.kernel.NeoStoreDataSource$3#3101ffd3' failed to transition from stopped to shutting_down. Please see the attached cause exception "Failed to rotate logs. Expected version: 5399, actual version: 5274, wait timeout (ms): 956815".
at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.shutdown(LifeSupport.java:497)
at org.neo4j.kernel.lifecycle.LifeSupport.shutdown(LifeSupport.java:206)
at org.neo4j.kernel.NeoStoreDataSource.stop(NeoStoreDataSource.java:766)
at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.stop(LifeSupport.java:458)
at org.neo4j.kernel.lifecycle.LifeSupport.stopInstances(LifeSupport.java:161)
at org.neo4j.kernel.lifecycle.LifeSupport.stop(LifeSupport.java:143)
at org.neo4j.kernel.impl.transaction.state.DataSourceManager.stop(DataSourceManager.java:120)
at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.stop(LifeSupport.java:458)
at org.neo4j.kernel.lifecycle.LifeSupport.stopInstances(LifeSupport.java:161)
at org.neo4j.kernel.lifecycle.LifeSupport.stop(LifeSupport.java:143)
at org.neo4j.kernel.lifecycle.LifeSupport.shutdown(LifeSupport.java:191)
at org.neo4j.kernel.impl.factory.ClassicCoreSPI.shutdown(ClassicCoreSPI.java:159)
at org.neo4j.kernel.impl.factory.GraphDatabaseFacade.shutdown(GraphDatabaseFacade.java:366)
at experiment.caseStudy.TestDatasetHealth.run(TestDatasetHealth.java:70)
at experiment.caseStudy.TestDatasetHealth.main(TestDatasetHealth.java:29)
Caused by: org.neo4j.kernel.impl.store.kvstore.RotationTimeoutException: Failed to rotate logs. Expected version: 5399, actual version: 5274, wait timeout (ms): 956815
at org.neo4j.kernel.impl.store.kvstore.RotationState$Rotation.rotate(RotationState.java:79)
at org.neo4j.kernel.impl.store.kvstore.RotationState$Rotation.rotate(RotationState.java:52)
at org.neo4j.kernel.impl.store.kvstore.AbstractKeyValueStore$RotationTask.rotate(AbstractKeyValueStore.java:311)
at org.neo4j.kernel.impl.store.kvstore.AbstractKeyValueStore$RotationTask.rotate(AbstractKeyValueStore.java:288)
at org.neo4j.kernel.impl.store.counts.CountsTracker.rotate(CountsTracker.java:154)
at org.neo4j.kernel.impl.store.NeoStores.flush(NeoStores.java:242)
at org.neo4j.kernel.impl.storageengine.impl.recordstorage.RecordStorageEngine.flushAndForce(RecordStorageEngine.java:480)
at org.neo4j.kernel.impl.transaction.log.checkpoint.CheckPointerImpl.doCheckPoint(CheckPointerImpl.java:160)
at org.neo4j.kernel.impl.transaction.log.checkpoint.CheckPointerImpl.forceCheckPoint(CheckPointerImpl.java:88)
at org.neo4j.kernel.NeoStoreDataSource$3.shutdown(NeoStoreDataSource.java:794)
at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.shutdown(LifeSupport.java:489)
In fact, in the Java program, I just read the information and do not write anything on the dataset.
Furthermore, to open the database using the following line of code, it takes 80 seconds on a 3.1GHz Core i7 MacBook with 16GB of Ram with 10GB of JVM arguments.
Is it normal to take this much of time for a dataset with the mentioned size?
GraphDatabaseService dataGraph = new GraphDatabaseFactory().newEmbeddedDatabase(storeDir);
Could you please guide me how can I repair the dataset to be easily shut down?
My application started to slowdown the phone after it ran in the background for a while.
After I recorded the cpu usage, the trace file shows me that JDWP take 99% of the cpu usage on the JDWP thread which is the only thread I can see in the trace file.
Is it possible that the JDWP (that Google says is Java Debug Wire Protocol) takes so much CPU or do I have a problem with the trace file? The phone start to work slower and get warm after the cpu usage jump so I'm pretty sure the usage data is OK.
Here are 2 trace files that show only JDWP:
https://drive.google.com/file/d/0B9MtungcpihwZnl0RFIwanktMEk/view?usp=sharing
Here is an album of before, in the middle and after the recording of the trace:
http://imgur.com/a/rOZ4g
The output of the command adb shell top -m 5 is here:
http://pastebin.com/2FJNVvZA
The JDWP thread shouldn't run very much; it's the thread that handles debugger commands, including some of the stuff that your IDE does automatically.
I can't remember ever seeing it taking a lot of CPU time, but I guess it could happen if you (or, more likely, some tool) is running a lot of commands.
Otherwise, you may have found a bug in the virtual machine (ART) or the IDE/tools.
If you feel like sharing the trace file, I wouldn't mind taking a look.
UPDATE 1: I've taken a look at the files. Indeed, there are no other threads than the JDWP thread. However, it's not using a lot of CPU -- hover your cursor over the top "JDWP." block and check the Wallclock time (4.344s) vs the CPU time (0.006s). You could also switch to the "Thread time" view instead of "Wall Clock time" in the dropdown box at the top.
Here's the human-readable part of one of the trace files:
*version
3
data-file-overflow=false
clock=dual
elapsed-time-usec=4345915
num-method-calls=410
clock-call-overhead-nsec=3808
vm=dalvik
*threads
1 main
14 Thread-7700
13 Thread-7699
12 Thread-7698
11 FileObserver
10 Binder_2
9 Binder_1
8 FinalizerWatchdogDaemon
7 FinalizerDaemon
6 ReferenceQueueDaemon
5 Compiler
4 JDWP
3 Signal Catcher
2 GC
*methods
0x6da675c0 android/ddm/DdmHandleProfiling handleChunk (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Lorg/apache/harmony/dalvik/ddmc/Chunk; DdmHandleProfiling.java -1
0x6da673c0 android/ddm/DdmHandleProfiling handleMPRQ (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Lorg/apache/harmony/dalvik/ddmc/Chunk; DdmHandleProfiling.java -1
0x6da67430 android/ddm/DdmHandleProfiling handleMPSE (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Lorg/apache/harmony/dalvik/ddmc/Chunk; DdmHandleProfiling.java -1
0x6da67468 android/ddm/DdmHandleProfiling handleMPSS (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Lorg/apache/harmony/dalvik/ddmc/Chunk; DdmHandleProfiling.java -1
0x6d8b4ca0 java/nio/ByteBuffer order (Ljava/nio/ByteOrder;)Ljava/nio/ByteBuffer; ByteBuffer.java 635
0x6d8b4410 java/nio/ByteBuffer <init> (ILjava/nio/MemoryBlock;)V ByteBuffer.java 116
0x6d8b44f0 java/nio/ByteBuffer wrap ([BII)Ljava/nio/ByteBuffer; ByteBuffer.java 108
0x6d8dd658 java/util/HashMap get (Ljava/lang/Object;)Ljava/lang/Object; HashMap.java -1
0x6d918008 java/util/Arrays checkOffsetAndCount (III)V Arrays.java 1731
0x6d9913a8 org/apache/harmony/dalvik/ddmc/ChunkHandler wrapChunk (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Ljava/nio/ByteBuffer; ChunkHandler.java 80
0x6d9807d0 android/os/Debug getMethodTracingMode ()I Debug.java -1
0x6d981100 android/os/Debug startMethodTracingDdms (IIZI)V Debug.java -1
0x6d9811a8 android/os/Debug stopMethodTracing ()V Debug.java -1
0x6da67040 android/ddm/DdmHandleHeap handleChunk (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Lorg/apache/harmony/dalvik/ddmc/Chunk; DdmHandleHeap.java -1
0x6da66e78 android/ddm/DdmHandleHeap handleHPIF (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Lorg/apache/harmony/dalvik/ddmc/Chunk; DdmHandleHeap.java -1
0x6d8be8d0 java/lang/Integer equals (Ljava/lang/Object;)Z Integer.java 208
0x6d8be940 java/lang/Integer hashCode ()I Integer.java 302
0x6d8be190 java/lang/Integer <init> (I)V Integer.java 88
0x6d8be740 java/lang/Integer valueOf (I)Ljava/lang/Integer; Integer.java 706
0x6d8b5240 java/nio/Buffer <init> (IILjava/nio/MemoryBlock;)V Buffer.java 97
0x6dc2d778 org/apache/harmony/dalvik/ddmc/DdmVmInternal heapInfoNotify (I)Z DdmVmInternal.java -2
0x6d8b5ec8 org/apache/harmony/dalvik/ddmc/Chunk <init> (I[BII)V Chunk.java 45
0x6d9d22a8 java/nio/ByteArrayBuffer get ()B ByteArrayBuffer.java 151
0x6d9d2000 java/nio/ByteArrayBuffer <init> (I[BIZ)V ByteArrayBuffer.java 41
0x6d9d2038 java/nio/ByteArrayBuffer <init> ([B)V ByteArrayBuffer.java -1
0x6d8b5fe0 org/apache/harmony/dalvik/ddmc/DdmServer dispatch (I[BII)Lorg/apache/harmony/dalvik/ddmc/Chunk; DdmServer.java 143
0x6d8b7128 dalvik/system/VMDebug getMethodTracingMode ()I VMDebug.java -2
0x6d8b7550 dalvik/system/VMDebug startMethodTracingDdms (IIZI)V VMDebug.java 182
0x6d8b76d8 dalvik/system/VMDebug stopMethodTracing ()V VMDebug.java -2
0x6d8ba1b8 java/lang/Number <init> ()V Number.java 33
*end
As you can see, the other threads are at least present in the header.
The header contains no references to non-system methods.
I won't say it's impossible that you've found some weird bug -- but I think it's more likely that your app was completely idle at this point, except for the minor work of answering the trace commands over JDWP, and the JDWP-only trace managed to confuse you a bit.
Your title mentions "50-100% cpu usage", though, which suggests that something is running. It's unclear to me from where you got those numbers -- maybe they include everything, not just your app? Try running adb shell top -m 5 to find out the top CPU consumers in your system.
An android application that I am currently developing was crashing (fixed that), due to what should have raised an IndexOutOfBoundsException. I was accessing a string in the doInBackground method of a class that extends AyncTask, from the variable arguments parameter (ie String...). I was accidentally accessing index 1 (not 0) of a one element variable argument string (mildly embarrassing...). When the application first crashed I looked at my logcat, (and many times again to confirm that I wasn't insane) and there was no stack trace for a RuntimeException to be found. I crash my phone quite often and there is always a nice little stack trace for me to look at and fix with, but I was puzzled by this. Here is the pertinent section of my logcat (which contains no stack trace for a runtimeexception), following a debug statement right before the line of code that was causing the crash:
W/dalvikvm(25643): threadid=11: thread exiting with uncaught exception (group=0x40c281f8)
D/dalvikvm(25643): GC_CONCURRENT freed 1249K, 25% free 12433K/16455K, paused 2ms+6ms
W/dalvikvm(25643): threadid=15: thread exiting with uncaught exception (group=0x40c281f8)
I/Process (25643): Sending signal. PID: 25643 SIG: 9
I/ActivityManager( 5905): Process com.trade.nav.ges (pid 25643) has died.
W/ActivityManager( 5905): Force removing r: app died, no saved state
I/WindowManager( 5905): WIN DEATH: win
I/WindowManager( 5905): WIN DEATH: win
I/SurfaceFlinger( 1746): id=3848 Removed idx=2 Map Size=4
I/SurfaceFlinger( 1746): id=3848 Removed idx=-2 Map Size=4
I/WindowManager( 5905): WIN DEATH: win
I/power ( 5905): *** acquire_dvfs_lock : lockType : 1 freq : 1000000
D/PowerManagerService( 5905): acquireDVFSLockLocked : type : DVFS_MIN_LIMIT frequency : 1000000 uid : 1000 pid : 5905 tag : ActivityManager
W/ActivityManager( 5905): mDVFSLock.acquire()
And after that, another activity starts.
For reference, here is the code that caused the crash:
private class LoadImage extends AsyncTask<String, Integer, Bitmap> {
String url = "";
//...
public LoadImage(ImageView iv, Context c) {
//...
}
protected Bitmap doInBackground(String... urls) {
// urls has one element
url = urls[1];
//...
}
//...
}
Any insight into what is happening would please me greatly, as I am curious about having never seen anything like this on the internet.
Thanks.
Edit: I have no filter set
Your threads are clearly crashing (note the thread exiting with uncaught exception on two different threads in the same process). The process is cleaning up after itself -- Sending signal indicates the process is sending a fatal signal to itself. So the question is why you aren't seeing a stack dump between these two.
The stack dump comes from RuntimeInit$UncaughtHandler, which is the framework-provided global uncaught exception handler. The process self-annihilation happens in the finally block. It's hard to see a way to get out of this without logging "FATAL EXCEPTION", unless something in Slog.e fails and throws.
I would guess that either something is failing in Slog.e, or somebody has replaced the framework's uncaught exception handler. The latter could happen if you've incorporated some external library into your app, such as a crash log catcher or an ad network, and the new handler doesn't log the exception but does kill the process.
You can track it down by attaching a Java-language debugger (e.g. Eclipse). By default it will stop on uncaught exceptions. From there you can trace it around, set breakpoints and single-step through the uncaught exception handler (if you have full sources), and so on.
As per fadden's suspect that external library could override uncaught exception handler, I started to investigate any possible libs. Turned out that GoogleAnalytics throttles crashes and prevents the stack trace from being displayed in logcat if you turn on enableExceptionReporting. I remove this line of code then everything gets back on track!! That could be the first time I was so happy to see crashes!!
I get a weird error.
I play with a MediaPlayer a mediastream (like shoutcast or icecast).
Sometimes suddenly on playing stream (total random) happens a error, the stream stops and restart.
OnErrorListener don't get triggered!
Logcat:
03-02 17:50:36.274: W/MediaPlayer(16799): info/warning (702, 0)
03-02 17:50:36.274: I/MediaPlayer(16799): Info (702,0)
or like this:
03-02 17:50:14.250: W/MediaPlayer(16799): info/warning (703, 0)
03-02 17:50:14.250: W/MediaPlayer(16799): info/warning (701, 0)
03-02 17:50:14.250: I/MediaPlayer(16799): Info (703,0)
03-02 17:50:14.250: I/MediaPlayer(16799): Info (701,0)
or
03-02 18:03:33.906: W/MediaPlayer(16799): info/warning (703, 126) <br>
03-02 18:03:33.906: I/MediaPlayer(16799): Info (703,126)
Any ideas on that?
Edit:
Ahh. One more information. 701 means MEDIA_INFO_BUFFERING_START and 702 means MEDIA_INFO_BUFFERING_END.
I think I could fix these if I increase buffer size?
Edit: But wait. BufferingSize is baked into the system. Damned. :)
As you wrote, buffering...
Sorry, No other suggestions.
It is buffering as you wrote - the only thing I'd like to add is that while it's annoying that it stops or starts, this information is very useful to your user. You may want to update him with a Toast (or a Crouton!) or indicate some sort of buffering status so that they don't blame your app (they will anyway usually!) or so that they know that it's likely their connection to blame - connecting to WIFI in this case is an action that would help.
I'm was seeing the same problem, but it only occurred when using a particular Bluetooth headset and the screen on my phone was off. The app that it occurred in was Just Playlists, a music player that I developed and support.
It only occurred when streaming via Wi-Fi and not via the cell network. I was able to get around the problem by going under Android's advanced Wi-Fi settings and disabling the "Wi-Fi optimization" option, which claims to "minimize battery usage when Wi-Fi is on." I had already used the advanced options to keep Wi-Fi always on.
The headset brand and model are Phiaton PS 210 BTNC. They support Bluetooth 3.0, which makes me suspect this is part of the issue. I've had this problem both under Android 4.1.x and 4.2.2. Here is a log excerpt from when the problem occurs and then recovers:
I/AwesomePlayer( 131): cache is running low (1.90 secs) , pausing.
W/MediaPlayer( 3028): info/warning (703, 0)
W/MediaPlayer( 3028): info/warning (701, 0)
I/MediaPlayer( 3028): Info (703,0)
I/MediaPlayer( 3028): Info (701,0)
I/audio_a2dp_hw( 131): suspend_audio_datapath: state 1
E/bt-btif ( 889): bta_av_str_stopped:audio_open_cnt=1, p_data 586a58f8
W/bt-btif ( 889): bta_dm_rm_cback:1, status:6
W/bt-btif ( 889): bta_dm_rm_cback:1, status:6
I/BluetoothA2dpServiceJni( 889): bta2dp_audio_state_callback
I/audio_a2dp_hw( 131): skt_disconnect: fd 46
D/A2dpStateMachine( 889): Connected process message: 101
D/A2dpStateMachine( 889): A2DP Playing state : device: 00:18:09:06:08:0C State:10->11
I/AwesomePlayer( 131): cache has filled up (6.00 secs), resuming.
I've yet to see what the impact on battery usage is after disabling the Wi-Fi optimization.