View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0012409 | MMA | General | public | 2014-12-03 22:23 | 2014-12-07 01:52 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.1.0 | ||||
| Target Version | 1.1.0 | Fixed in Version | 1.1.0 | ||
| Summary | 0012409: Battery utilization seems higher / Mediascanner can run non-stop | ||||
| Description | Several users have complained about high battery utilization in recent builds. With build 347 and intermittent testing, I noticed that: - On a Nexus 5: Battery utilization for MediaMonkey was 7% - On a Samsung Captivate: Battery utilization of the MediaServer was at 20% despite the fact that I barely used MMA (I just ran it a couple of times). Is it possible that recent MMA builds are interacting with Android in some manner that's causing the MediaScanner to run more often? | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 352 | ||||
|
|
I was able to replicate this as follows: 1 performed a sync operation with 0001113:0003300 tracks --> one of the playlists on the auto-sync list wasn't completely synced due to lack of space. As a result, the playlist was missing from the device, and only about 20MB remained available on the SD card (I'm not sure whether this is related to the bug or not). 2 Re-start MMA --> mediascanner hourglass appears for ~10 seconds 3 Click Playlists --> mediascanner hourglass appears and doesn't go away. Submitted debug log after waiting 5 minutes. Note: while the hourglass was spinning, there seemed to be a lot of network activity--not sure if this was coming from MMA. Debug log ID: N5POT469VA Note: even when this bug doesn't occur, it seems that the mediascanner is often running in build 248. |
|
|
The issue is in refreshing of FolderFragment. It uses broadcast to refresh instead of ContentObserver. In Rusty's case 1000 broadcasts were sent to receiver that process it redundantly one by one. It caused low memory issue when MMA was terminated by Android. 1. Broadcasts are probably not a good choice for this type of operation and it should be replaced by ContentObserver, that is used for all other views. 2. Maybe the number of notifications can be somehow reduced too. 3. Another issue here is the consequence, i.e. that ContentService was not finished after MMA was restared. It is related to 0012325. Maybe it will be better to resolve 12325 first, then try to reproduce this and then fix 1 and 2. |
|
|
1. and 2. are duplicates of 0012413 |
|
|
add 1. fixed |
|
|
2) added transactions 3) fixed Fixed in build 352 |
|
|
Verified 352. |
