Music app high power consumption when paused

Bug #1518764 reported by Patrik Turzák on 2015-11-22
62
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Canonical System Image
High
Michał Sawicz
Ubuntu Music App
Undecided
Unassigned
qtmir (Ubuntu)
High
Michael Terry
unity8 (Ubuntu)
High
Michael Terry

Bug Description

bq E5 HD, Ubuntu 15.04 (OTA-8)

The battery level drops fast when the music app runs in the background with music paused (and headphones unplugged).

Related branches

Andrew Hayzen (ahayzen) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

This sounds like the platform is not suspending the application when no music/audio is playing (I think this is the current expected situation). I'm adding QtMir as affected so that they can investigate if this is the case.

Also this should also improve once we have a normal app lifecycle with work going on upstream to us.

Victor Thompson (vthompson) wrote :

My understanding was that the music app is never suspended--regardless of the playback state.

Once the lifecycle exception has been lifted, however, this should no longer be an issue, as Andrew stated.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in qtmir (Ubuntu):
status: New → Confirmed
Uranicus (matthias.ritter) wrote :

BQ4.5, 15.04, OTA-8

I have the same issue. I have attached a picture with the battery status.

I have only opened the Music app without playing any music (at 24 h) and I have closed it again at 6 h. Battery drain started at 24 h and stopped at 6 h.

I have not used the Music app after OTA-7 but before this did work fine.

Andrew Hayzen (ahayzen) wrote :

@Victor, as part of bug 1423787 the lifecycle was changed so that we only have the exception when the app is focussed or is playing. "Ideally the system state request (wakelock) should just be enabled and active when the music-app is also active, playing songs.". However, maybe this has now been broken?

Michael Devenish (mdevenish) wrote :

Same issue for me with my BQ 4.5. This only happened after upgrading to OTA-8.

Gerry Boland (gerboland) wrote :

Music app is part of the lifecycle exemptions list. When it is launched, QtMir obtains a wakelock for it to stop the system deep-suspending. This means that while Music app is open, your system cannot deep suspend, which is mainly a low-power CPU state.

Other apps however will still be frozen if they are not in front. Just Music app will never be frozen.

Since system not deep-suspended, it is possible for **any other process** on your phone to use as much CPU as it wants.

So if any of the daemons (and the music app) has a bug, it might end up consuming all your battery while your display is off.

Just testing it on Bq with today's rc-proposed image (190):
1. launched Music app. Wakelock held by shell for it ("power-cli list" prints an "active" lock held) - CPU usage zero (just watching "top"). Looks reasonable.
2. Blank the screen. Wakelock still held. CPU usage zero. Looks ok.
3. lit screen, playing a song. Wakelock held. CPU usage about 20%
4. blank screen while song playing. CPU usage stays around 20%.

This state could be improved as unity8.log is reporting frames being dropped: this means Music app is drawing, even though display is off - pointless. Fixing bug 1475678 should resolve this.

The remaining CPU is being used by media-hub and pulseaudio to play the audio.

5. pausing the song, and letting the display blank, I see almost zero CPU usage. Wakelock always held though. But that's as good as we can do.

With some playing around, I've not managed to get Music app to mis-behave: if no music is playing, music-app using no CPU really. So I suspect another process on the phone is misbehaving.

Could someone here who suffers from this issue please "adb shell" into their phone and run "top" and look at what processes are using CPU while your display is off.
Thanks
-G

Josué (j2g2rp) wrote :

Sorry for the quality. BQ 4.5 ubuntu edition. Woriking through phablet-shell in terminal.

Josué (j2g2rp) wrote :

I deleted the image because i think wasn’t representative because I took it very fast and since it was laggy appears some peaks in the cpu usage:
now attached the usage with the music player paused by MPRIS:

Josué (j2g2rp) wrote :

now music player playing

Michael Devenish (mdevenish) wrote :

I've used adb shell and run top for a base case of no apps loaded (and screen off), and with the music app open but not playing music (and screen off).

Compared to the base case I see the following main differences when the music app is open:

disp_config+ (2 PIDs) runs most of the time
qmlscene runs occasionally
powerd and upowerd didn't run

This is with OTA-8 on my phone.

Selene ToyKeeper (toykeeper) wrote :

Confirmed on arale rc-proposed 181.

This graph shows power use with the music app opened (but paused), then with the music app closed, then again with it open (and paused). The phone was in flight mode for minimum power use.

Average power with the music app open was ~135mA, while power was barely above zero with the app closed.

The big spikes are when the screen was on and I was interacting with the phone.

Changed in canonical-devices-system-image:
status: New → Confirmed
importance: Undecided → High
assignee: nobody → kevin gunn (kgunn72)
milestone: none → ww02-2016
tags: added: power-bugs
summary: - Music app high power consumption
+ Music app high power consumption when paused
Michael Zanetti (mzanetti) wrote :

@gerboland:

Qtmir should not hold a wakelock for lifecycle excempt apps. When the music app is playing music, media-hub will hold a wakelock for it.

Changed in qtmir (Ubuntu):
importance: Undecided → High
Changed in music-app:
status: New → Invalid
Michael Terry (mterry) wrote :

I believe this is my fault (a regression from https://code.launchpad.net/~mterry/qtmir/no-touch-no-lifecycle/+merge/272791).

I'll look at this.

Michał Sawicz (saviq) on 2015-12-03
Changed in qtmir (Ubuntu):
assignee: nobody → Michael Terry (mterry)
status: Confirmed → Triaged
Changed in canonical-devices-system-image:
status: Confirmed → Triaged
assignee: kevin gunn (kgunn72) → Michał Sawicz (saviq)
Changed in unity8 (Ubuntu):
status: New → Incomplete
status: Incomplete → Triaged
importance: Undecided → High
assignee: nobody → Michael Terry (mterry)
Pat McGowan (pat-mcgowan) wrote :

Add to hotfix if one is available

Changed in canonical-devices-system-image:
milestone: ww02-2016 → ww50-2015
Michał Sawicz (saviq) on 2015-12-04
Changed in qtmir (Ubuntu):
status: Triaged → In Progress
Changed in unity8 (Ubuntu):
status: Triaged → In Progress
Changed in canonical-devices-system-image:
status: Triaged → In Progress
Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qtmir - 0.4.7+16.04.20151210-0ubuntu1

---------------
qtmir (0.4.7+16.04.20151210-0ubuntu1) xenial; urgency=medium

  [ Nick Dedekind ]
  * [ Nick Dedekind ]
  * Request app closing rather than killing.

  [ Daniel d'Andrada ]
  * Add MirSurfaceItem.fillMode and ensure items and buffer are in sync
  * Make Session hold multiple surfaces

  [ Michael Terry ]
  * Don't hold a wakelock on apps that are exempt from lifecycle
    management. (LP: #1518764)

  [ Michał Sawicz ]
  * Add MirSurfaceItem.fillMode and ensure items and buffer are in sync
  * Don't hold a wakelock on apps that are exempt from lifecycle
    management. (LP: #1518764)

 -- Gerry Boland <email address hidden> Thu, 10 Dec 2015 13:08:47 +0000

Changed in qtmir (Ubuntu):
status: In Progress → Fix Released
Michał Sawicz (saviq) on 2015-12-11
Changed in unity8 (Ubuntu):
status: In Progress → Fix Released
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers