IssueTracker

This issue does not reproduce with dev preview 4.

Closing this issue as per comment #2 from reporter.

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

I've been running the latest version of the master branch of the Android Open Source Project on a Nexus 4, which has been sitting on my desk for 24 hours. I have 94% of battery left, and mediaserver isn't even on the list of battery users. Same thing on a Mobile Nexus 7.

If someone can reproduce this problem on a Nexus 4 or Nexus 7 with the latest version of the master branch of the Android Open Source Project, please let me know.

@jbq: I don't have either of those Nexus devices, but on my Galaxy S3 running Android 4.1.1, I can reliably reproduce this error by running the app "Puzzle and Dragons" (free), then returning to my home screen without explicitly shutting down the app.  Can you see if you get the same result in your setup?

[Comment deleted]

[Comment deleted]

#37: problems on both Nexus 4 and Nexus 7 on 4.2.2. But perhaps that is not the latest version of AOSP.

I'm on 4.2.2 Nexus 4 and I also can recreate the problem by running Puzzle
and Dragons and then leaving it on in the background.

Can also confirm with it in the background if I put my ear to my speaker it
is definitely making some quiet static noise until I kill the app.

So I guess its powering the speaker etc to drain the battery.

@#39: That would explain why when this problem is active, pressing the volume up/down buttons changes the media volume instead of the ringtone volume.

[Comment deleted]

Please don't comment unless you are helping with the investigation, thanks. I'll be deleting comments that add too much noise, so that we can stay focused on actually trying to solve this problem.

This issue is known to happen on retail builds of 4.2.2 on both Nexus 4 and Nexus 7. I'm trying to reproduce on the master branch, which contains a few thousand additional changes.

#35: unfortunately I can't try that game, as it's only available through Google Play Store, and I don't have access to that.

@40 Holy shit I never even realized these two issues are connected. That
problem has always bothered me to no end man.

[Comment deleted]

#39, #40: this is interesting, it could suggest that this might be a class of application bugs or application-triggered bugs, possibly applications playing continuous silent sound in the background.

Does anyone experience the same high power usage from media server on Nexus 4 or Nexus 7 running retail 4.2.2 while the volume buttons behave normally (i.e. change the ringtone volume)?

[Comment deleted]

If anyone gets a Nexus 4 or Nexus 7 into the state where both the battery drains quickly because of MediaServer and the volume controls change the media volume instead of the ringtone volume, please try to kill the apps in the task switcher (swipe them away), one by one, testing the behavior of the volume controls each time.

If the volume controls return to normal, please make a note of the last application you killed, and please see if the MediaServer battery usage returns to normal.

[Comment deleted]

@jbq thanks for looking into this!  I, too, have neither of the Nexi.  I'm experiencing this on a Galaxy S3 from Verizon.  It hadn't occurred to me that it could be due to reseller mods but I wouldn't be surprised.

Anyway, this happens to me usually when I boot up the phone.  Later, it happens on occasion when I play music.  I can exit the player but the media service stays active and keeps the device in the awake state (screen off, processor running).

I've read many theories out there: corrupt SD card or corrupt file (scanned my SD and files, and they're fine); file names that are too long (causing a buffer limit/overflow); file names that include '_' or '~' (which act as wildcards, causing DB queries to explode in complexity).  I've tried cleaning up my file names.  I believe I've removed any underscores and tildes.  I still experience the stuck-awake situation, but seems perhaps a bit less?  Haven't seen any obscenely large file names either.

BTW, just stopping the Media service isn't always enough.  Frequently I have to clear it from the cached applications as well.

#49 - What you're describing would be consistent with the possibility that a background application is streaming silence to the media server. In this case, the media server does all the hard work, so it's getting the battery blame, but the bug is on the application side. In this case as well, it's quite expected that killing the media server itself wouldn't help: it'd naturally restart itself right away and continue getting the stream of silence from the application that's still there.

jbq: Two things I don't understand about that theory:

First, if an app is just "streaming silence" to the media server, wouldn't the app itself show up in the list of active apps alongside Media Server, since supposedly it would have some thread actively sending data to the server?  I would think the app would be holding open a wakelock to do that.  In my case, P&D doesn't show up anywhere in the wakelock list when it's sitting idle.

Second, if it WERE a simple "app left audio streaming" situation, why does the battery drain so much faster in this scenario than when people are actually listening to music?  Is the MediaServer so inefficient that it can drain a battery in 4 hours or less just processing a simple audio stream?  There are lots of devices with much smaller, less powerful batteries that can do constant audio streaming for far longer periods of time than that.

Can I float another theory that might help write a simple test case for this?  Suppose the app is forgetting to properly close its stream of data when it goes idle, and this causes the Media Server to remain "on the line" waiting for more input, perhaps to fill an incomplete buffer or something along those lines.  Could it be that the server is getting stuck in a CPU spin waiting for more data on that stream instead of closing the connection gracefully?

I'll add that when I repro this problem with P&D (put it idle and have MediaServer draining the battery), I start seeing significant performance issues in other apps as well (for example, if I launch "Jetpack Joyride", the side-scrolling background is very jerky until I shut down P&D).  This suggests that one of the background modules is eating a lot of CPU cycles.

#51/#52 - those seem like valid possibilities. Note that an app wouldn't need to hold a wakelock itself if it's responding to a request for more data from the media server: the media server's wakelock would be enough for that.

The data I see from Issue 36949180 suggests a 10-hour battery life. Along with the comment in #39 that suggests that the audio amplifier is kept on, this doesn't seem entirely impossible.

I'd be very surprised if the media server had any explicit busy waits, but there's obviously the possibility of bugs, which is what we're tracking here.

Your experience with the 2 games definitely definitely suggests that P&D in the background causes something to happen that slows down JJ.

It sounds like it would be possible to write a test case for that, but we're not exactly sure what we're looking for. Sadly, I haven't written any Android apps for more than 5 years, so I can't whip a quick test in a few minutes. Another approach would be to have the developer of such an app try to reproduce the same issue directly on AOSP, so that they could add some debugging information both in their app and in Android and try to understand what interactions are going on that before and during the period of high battery drain.

For me the problem seems to be associated with switching the phone on.  After booting the phone I need to terminate the media process about 10-15 times in the first 2-3 hours it's on otherwise it drains the batter so fast it can't actually be charged.

However apart from that the phone is usually ok (and I've a feeling that the times it's not might be when something has crashed and it has re-booted but I haven't noticed).

#54 - This could very well be caused by a specific application that runs at startup, as opposed to the startup sequence. I'll note that my pure AOSP build doesn't have that issue at boot.

I'm not won over by the "rogue app streaming null data" theory.  I've gone through and killed every other application and the device still stays in the awake mode.  It's not until I finally kill the media server that I feel the processor cool off and the device eventually goes to sleep.  The theory meshes best with my experience is that the media server is stuck performing some scanning operation where it either never ends or is much more involved than it needs to be.  Just my 2 cents.

#56 - do you have logs, or sample code, or anything that could be used to try to diagnose this in a controlled environment?

[Comment deleted]

I've looked through the logs periodically and haven't seen anything obvious.  I'll try again, or better yet, if I can get my development environment back up (haven't developed on droid in a while) I'll try attaching the debugger...

I recall that in the early days of this bug, many people were putting it down to something that the media server was scanning. I tried to track this down at one point and witha lot of music on my phone, experimented with deleting large batches of music. At one point, it stopped draining the battery.
Is it possible the media server is scanning a corrupt file and gets stuck scanning it?
Has anyone else tried selectively (more selectively than my bulk deletes) to remove files and does it make a difference?

#60 I used to see this same thing on my Nexus 4.
I managed to fix it by removing a soundboard style app that I had which had about 700 short mp3 files in it. When I uninstalled that app the problem went away.

For anyone still getting the issue, try uninstalling any apps with lots of sound files, or re-installing ones with sound that you really must use.

I found that when i had moved real racing 2 and 3's /android/data folders to my sd card using the app gltosd, then the media server would at boot get stuck for a few hours and drain a large amount of my battery.  These data folders contain thousands of files for the games.

I moved the data files to free up internal memory, as my galaxy s2 only has 16GB, but my sd card has 64gb. Once i moved the data folders back to internal memory, the media scanner issue stopped for me.

So if you want to try reproduce the issue, the above i think will provide you with a method.

I've seen the corrupt mp3 suggestion before, and tried using a prog on my desktop to scan all the files and check for any corrupt ones. It didn't work :(

 only thing that has worked for me is taking out the sd card!

@jbq: Here are a couple log entries gathered while the media service is stuck that might be of interest.  Filtered for pid=15986 too but got nothing.  I'll see what else I can come up with; this was just a quickie instead of doing what I'm supposed to be doing. :-)  Also, feel free to PM me.


06-16 10:17:37.805: W/PowerManagerService(722): type=PARTIAL_WAKE_LOCK              'MediaScannerService' active (mS=0)  activeT=17371030  uid=10030  pid=15986
06-16 10:17:38.025: V/AlarmManager(722): trigger ELAPSED_REALTIME_WAKEUP or RTC_WAKEUP
06-16 10:17:38.095: V/AlarmManager(722): trigger ELAPSED_REALTIME_WAKEUP or RTC_WAKEUP
06-16 10:27:24.973: I/rmt_storage(129): wakelock acquired: 1, error no: 110
06-16 10:27:25.163: I/rmt_storage(129): rmt_storage_client_thread: /boot/modem_fs2: clnt_h=0x2 About to block rmt_storage client thread (th_id: 1102016208) wakelock released: 1, error no: 0

"media scanner" does not equal "media server", they are different things, running in different processes, and show up separately in battery stats.

 my battery profile only shows "Media".  which would that be?  ( I'd assumed it was an umbrella)

Let's be sure that we know which devices we're talking about here. Outside of a Nexus (Galaxy Nexus and newer), there's no knowing what might have been tweaked by hardware manufacturers, especially on devices with SD cards or USB Mass Storage, and AOSP won't have access to those manufacturers' code.

 got it.   I won't muddy the waters  more.  I'm on a Galaxy S3,  Verizon. I  was hoping such core functionality would be common, but no?

I'm on a Samsung Note 2 via T Mobile and have the same issue at times. Restarting my device apps to resolve the issue I'm not sure what starts it.I do not use my device for music but I do use it for movies. I have heard about the issue with pictures that are corrupt and have removed all my pictures waiting to see if that helps with mine.might if you only started after the upgrade to 4.1.2.

[Comment deleted]

[Comment deleted]

Those components can't be expected to be common between devices. None of the Open Source components can. I'm deleting the reports that apply to non-AOSP devices as those can't be reproduced in AOSP - such issues should be reported to the manufacturers, possibly via the carriers if those are carrier-supported devices.

Could someone try to reproduce this bug with mp3's from comments #58 and #61 of issue 36914590?
http://code.google.com/p/android/issues/detail?id=6765#c58
http://code.google.com/p/android/issues/detail?id=6765#c61

@#72: I'm sorry, but are you really telling us that Google won't support its own OS on devices other than the Nexus 4 and Nexus 7?  If everyone is telling you there's an Android Core Component causing a problem and giving you ideas on how to reproduce the issue, why are you being so evasive about it?  There's no evidence that this "Media Server" component has been overridden in any way by any of the device manufacturers or carriers.

Are you also really saying that Google has no ability to test its own software in its own environment (eg. Google Play Store) for compatibility with applications written to run on it?

No wonder I've been seeing so many dissatisfied customers. :P  Keep in mind, relatively few of us are willing to void our device warranties or support contracts with our carriers by rooting our devices and installing AOSP.

@#74 The video/audio/camera HALs run in the mediaserver process and vary for each OEM.
Also - even if mediaserver was entirely Google framework code (which it isn't) OEMs still modify the Google framework code for their own features.
Asking this forum to support such modifications is unfair.

I wasn't aware of that.  Sorry, then.  But then the question becomes, how does it become so easy for an OEM to screw up these components in such a way that it causes such severe operability problems for their customers?

Perhaps it is a result of OEM modification, but if so it is happening with a number of OEMs, which points to a generic problem or weakness.

My battery problem is related to media scanner not media server - as best as I can tell. Is there a separate thread on that topic that I should be following?

#74 and everyone: sorry about the confusion, I realize how frustrating this situation is.

Because of the Open Source nature of Android, it's not really possible to know whether this part of the Operating System got modified between Google and the end-users on any device other than the ones that are directly engineered by Google.

In turn, because of that, and somewhat naturally, the only issues that can be fixed within the Android Open Source Project are the issues that exist here in the first place. The best way to know if an issue exists here is to try to make it happen within the Open Source version of Android. In turn, pretty much the only devices on which it's possible to run the Open Source version of Android are Nexus devices. That's why I've been focusing on those, especially since I know that the issue is reproducible on the retail configurations of both Nexus 4 and Nexus 7. From here, the most likely engineering approach is to reproduce this issue on either of those devices, to fix it in the Open Source code, and from here it'll trickle through the Android ecosystem.

Within the Android Open Source Project, we explicitly don't want to rely on anything that is only available to Google employees, since that would be unfair to all the other Open Source contributors who participate in the development of Android. The less we rely on private information or tools, the more people can work on trying to reproduce and fix this issue.

Thanks for understanding and for participating in the Open Source process.

#78: I suspect that this might be a separate issue, especially in light of #65. I can't seem to find a clear cut report that unambiguously applies to the media scanner, and it might make sense to open a new report.

As you report this, please be sure to identify which device and version of Android you have. Because of the media scanner's role, any information you might have about the media files you have on the device will be helpful. If you have the Android SDK installed, please run "adb bugreport" and store the result privately, it might contain useful information that could help diagnose what's going on.

#78 When I upgraded to 4.1.2 on Galaxy S2, which is where the mediascanner problem started from for me, the Flickr app had about 40,000 image files stuffed in a folder. Deleting these restored my battery life to something approaching normal.

@justdanpo/#73, I can reproduce a problem with the first file you linked to, but not the second. And while the problem triggered by that first file will certainly cause high battery usage by media server, it's not clear whether everyone seeing high media server battery usage is running into this particular problem (which is related to id3 version 2.4 metadata handling). We'll certainly fix this particular problem ASAP though.

[Comment deleted]

[Comment deleted]

[Comment deleted]

#84: The root issue in your case is related to the low-level SD card handling on your specific device, which forces the media scanner to rescan the card. This is not the issue we're hunting here, we're looking for situations where the media server ends up using a lot of CPU continuously. You should report your experience with Samsung so that they can investigate your issue deeper.

Note that the media scanner only scans the card after it has been mounted, which should only happen after it has been checked for errors. If you yanked out the card at some point, I would expect at most one filesystem check, after which the card is either mounted successfully, or is unmountable and needs to be reformatted.
If the card is continuously remounted, that seems like a different problem, perhaps a bad contact.

[Comment deleted]

For mediascanner issues, please see Issue 36949180 (that's exactly what's going on in comment #88). What we're looking for here is about issues not related to the media scanner. I"m deleting the comments related to the media scanner running each time the SD card is mounted.

Why does mediaserver work for system sounds even in vibrate or silent mode? In both modes, no sound playback is requiered for those system events.

[Comment deleted]

My battery drained from 86% to 57% in a very short period of time.  When I checked battery stats Media Server is taking up a big chunk of the battery again.  Based on some of the comments made from last time I tried adjusting the volume (my media volume was turned all the way down, and my phone on vibrate) sure enough while looking at the battery stat screen the volume keys were adjusting the media volume not the ringer volume.  I had just finished playing an Adobe AIR based game (from the Play store) called Nono Logix(https://play.google.com/store/apps/details?id=air.com.ooblada.nonologix), I went into the app info screen and did a Force Close on the app, tested the volume keys and it changed the ringer volume instead of the media volume.  I'm not sure if this problem is being caused by the game itself or Adobe Air, but hopefully that gives a bit more insight.

Thanks #92, this seems to confirm that one way to trigger the issue is to run certain applications (and the issue might exist with some applications that run at startup).

It also confirms that in your case as well there's a correlation between the high battery usage and the volume keys adjusting the media volume.

Is this also reproducible for you? Meaning, can you make this happen each time you run that game? (the volume keys should be enough of a symptom that you don't need to discharge your battery over it).

I just reproduced it twice in a row with that game.

Thanks, that's good information to have.

Hi Guys,
I think I have another way to recreate this error with Google play music and a Nexus 4 Stock AOSP 4.2.2,
Ok so my day does, Get in the car, Bluetooth connection, open lock screen, Google play music widget, Play songs....
Get to work, turn off car (Bluetooth automatically disconnections) music stops!...
But I experience the same volume control issue (ie pressing up and down doesn’t turn the phone up and down but the media volume up and down)
Battery sinks like a brick in a pond.
I can reproduce this at ease. Let me know if you want to so send any logcats etc.
Cheers
Mike

Thanks #96. Your description also reminds me of Issue 36949180, so you might be experiencing one, or the other, or both, or maybe they're actually the same...

Yeah, Just been reading 50751 whoever, If I don't listen to music I don't have this issue,

My bluetooth normally works fine other then when im on the phone etc etc, soon as i play music i get this.

Same issue, T-Mobile S3 SGH-T999, Android version 4.1.2. Started about 2 weeks ago, roughly around time there was a OTA update. Didn't have issue before this. After turning phone on in morning, it gets physically hot to touch, and battery is drained after about 4 hours. GSam battery app is showing 'Media' as draining battery. If I kill the app then normal battery usage from that point onwards throughout the day.
Thinking that some of the comments in this bug report mentioned that the media scanner just has to do it's thing and complete, I've left it running all day, but it runs until battery is flat in about 4 hours. This has rendered my phone unusable and useless. Temporary work around is just to remember to kill the media scanner app every time I turn on the phone.

In my experience, killing "media" doesn't seem to work; it just comes back (or possibly doesn't die at all). Is root required to kill it effectively? My only recourse has been to keep the phone on & on charger rather than turning it off nightly and back on (recharged) when starting the day.

[Comment deleted]

im having the same issue as #96 with my nexus 4, the battery just drains in 4 hours after playing music via bluetooth, and controlling the music thru the bluetooth device on my motorcycle helmet, my bluetooth device is a sena SMH10 and a nexus 4 16gb

[Comment deleted]

[Comment deleted]

[Comment deleted]

Nexus 4 with 4.2.2. This happens to me approximately once a week. There's a rogue process that keeps draining the battery by staying active in the background while the screen is off. I've noticed the following process that randomly become the culprit - Google+, Whatsapp, Mediaserver, Maps, AndroidOS. It happens randomly & often the process changes. If I kill the process or reboot the phone, it's good till the next recharge.
It's difficult to reproduce but are there any log files I can send?

I have the same problem even installing the new 4.3. I have a nexus 7 3g (2012)

I've tried to restore default many times but the bug continues although installing any aplications. Also i've tried to cancel the google's account synchronism but it doesn't work the media server always be there to drain my battery

I hope could find a solution soon because i desperate.

PD: i've attach a screenshot of the problem with the new android 4.3

I've recently started noticing this issue on my Nexus 4, Mediaserver accounts for over 40% of my battery usage at a given time. My battery life has decreased to the point that I consistently get a low battery warning by the end of the day, even if I've barely touched my phone. Is there any logs or information I can provide that would help diagnose the issue?

Does not appear to be related to app usage since it persists even if I restart my phone. I have bluetooth/wifi/mobile data on at all times if that helps.

Related to #35, I do in fact have the Puzzles and Dragons app installed and play it occasionally.

my issue 36904400 continues with andrid 4.3 on my nexus 4, i listen to music via bluetooth and it EATS battery 10% per like 20 minutes of music heard.

Seeing this on a brand new Nexus 7 FHD.

Mediaserver is 49% of my battery use and I don't have any media to speak of -
like how many movies can you cram into 16GB anyway?

Ready to help sort this out, it's quite a black eye.

[Comment deleted]

[Comment deleted]