Revision history [back]

When a user switches between ambiences in SFOS 3.0.0.5 the voicecall-ui process starts to constantly use 1 to 1.6 percent CPU. Normally voicecall-ui is quite dormant, using CPU only occasionally (unless the voicecall UI is actually used).

Voicecall-ui can be restarted with a command: systemctl --user restart voicecall-ui-prestart

This behavior is similar to this previous case but triggered differently: https://together.jolla.com/question/188325/sailfish-x-voicecall-ui-prevents-deep-sleep/

When a user switches between ambiences in SFOS 3.0.0.5 the voicecall-ui process starts to constantly use 1 to 1.6 percent CPU. Normally voicecall-ui is quite dormant, using CPU only occasionally (unless the voicecall UI is actually used).

Voicecall-ui can be restarted with a command: systemctl --user restart voicecall-ui-prestart

This behavior is similar to this previous case but triggered differently: https://together.jolla.com/question/188325/sailfish-x-voicecall-ui-prevents-deep-sleep/

When a user switches between ambiences in SFOS 3.0.0.5 the voicecall-ui process starts to constantly use 1 to 1.6 percent CPU. Normally voicecall-ui is quite dormant, using CPU only occasionally (unless the voicecall UI is actually used).

Voicecall-ui can be restarted with a command: systemctl --user restart voicecall-ui-prestart

This behavior is similar to this previous case but triggered differently: https://together.jolla.com/question/188325/sailfish-x-voicecall-ui-prevents-deep-sleep/

When a user switches between ambiences in SFOS 3.0.0.5 the voicecall-ui process starts to constantly use 1 to 1.6 percent CPU. Normally voicecall-ui is quite dormant, using CPU only occasionally (unless the voicecall UI is actually used).

Voicecall-ui can be restarted with a command: systemctl --user restart voicecall-ui-prestart

This behavior is similar to this previous case but triggered differently: https://together.jolla.com/question/188325/sailfish-x-voicecall-ui-prevents-deep-sleep/

Update 2018.11.10

It seems that this not so much of a problem of the voicecall-ui directly, but a problem of voicecall-ui-prestart.service or how it is run or started in the background.

When the service is stopped with the command systemctl --user stop voicecall-ui-prestart, and then started manually with /usr/bin/voicecall-ui , or by starting it from the GUI (the Phone app), the problem is not triggered anymore. triggered. So it could be that it might be related on how ambienced tries to restart the preload service (if it tries to do that when switching between the ambiences).

When a user switches between ambiences in SFOS 3.0.0.5 the voicecall-ui process starts to constantly use 1 to 1.6 percent CPU. Normally voicecall-ui is quite dormant, using CPU only occasionally (unless the voicecall UI is actually used).

Voicecall-ui can be restarted with a command: systemctl --user restart voicecall-ui-prestart

This behavior is similar to this previous case but triggered differently: https://together.jolla.com/question/188325/sailfish-x-voicecall-ui-prevents-deep-sleep/

Update 2018.11.10

It seems that this not so much of a problem of the voicecall-ui directly, but a problem of voicecall-ui-prestart.service or how it is run or started in the background.

When the service is stopped with the command systemctl --user stop voicecall-ui-prestart, and then started again manually with /usr/bin/voicecall-ui, or by starting it from the GUI (the Phone app), the problem is not triggered. So it could be that it might be related on how ambienced tries to restart the preload service (if it tries to do that when switching between the ambiences).

When active, the condition can be cured without restarting voicecall-ui-prestart service simply by starting the Phone app manually. After this has been done once, the CPU usage settles to normal levels. Also sequential switches of ambience do not trigger the bug anymore after this.

When a user switches between ambiences in SFOS 3.0.0.5 the voicecall-ui process starts to constantly use 1 to 1.6 percent CPU. Normally voicecall-ui is quite dormant, using CPU only occasionally (unless the voicecall UI is actually used).

Voicecall-ui can be restarted with a command: systemctl --user restart voicecall-ui-prestart

This behavior is similar to this previous case but triggered differently: https://together.jolla.com/question/188325/sailfish-x-voicecall-ui-prevents-deep-sleep/

Update 2018.11.10

It seems that this not so much of a problem of the voicecall-ui directly, but a problem of voicecall-ui-prestart.service or how it is run or started in the background.

When the service is stopped with the command systemctl --user stop voicecall-ui-prestart, and then started again manually with /usr/bin/voicecall-ui, or by starting it from the GUI (the Phone app), the problem is not triggered. So it could be that it might be related on how ambienced tries to restart the preload service (if it tries to do that when switching between the ambiences).

When active, the condition can be cured without restarting voicecall-ui-prestart service simply by starting the Phone app manually. After this has been done once, the CPU usage settles to normal levels. Also sequential the consequent switches of ambience do not trigger the bug anymore after this.launching the app once.

When a user switches between ambiences in SFOS 3.0.0.5 the voicecall-ui process starts to constantly use 1 to 1.6 percent CPU. Normally voicecall-ui is quite dormant, using CPU only occasionally (unless the voicecall UI is actually used).

Voicecall-ui can be restarted with a command: systemctl --user restart voicecall-ui-prestart

This behavior is similar to this previous case but triggered differently: https://together.jolla.com/question/188325/sailfish-x-voicecall-ui-prevents-deep-sleep/

Update 2018.11.10

It seems that this not so much of a problem of the voicecall-ui directly, but a problem of voicecall-ui-prestart.service or how it is run or started in the background.

When the service is stopped with the command systemctl --user stop voicecall-ui-prestart, and then started again manually with /usr/bin/voicecall-ui, or by starting it from the GUI (the Phone app), the problem is not triggered. So it could be that it might be related on how ambienced tries to restart the preload service (if it tries to do that when switching between the ambiences).triggered.

When active, it seems that the condition can be cured without restarting voicecall-ui-prestart service simply by starting the Phone app manually. After this has been done once, the CPU usage settles to normal levels. Also the consequent switches of ambience do not trigger the bug anymore after launching the app once.

When a user switches between ambiences in SFOS 3.0.0.5 the voicecall-ui process starts to constantly use 1 to 1.6 percent CPU. Normally voicecall-ui is quite dormant, using CPU only occasionally (unless the voicecall UI is actually used).

Voicecall-ui can be restarted with a command: systemctl --user restart voicecall-ui-prestart

This behavior is similar to this previous case but triggered differently: https://together.jolla.com/question/188325/sailfish-x-voicecall-ui-prevents-deep-sleep/

Update 2018.11.10

It seems that this not so much of a problem of the voicecall-ui directly, but a problem of voicecall-ui-prestart.service or how it is run or started in the background.

When the service is stopped with the command systemctl --user stop voicecall-ui-prestart, and then started again manually with /usr/bin/voicecall-ui, or by starting it from the GUI (the Phone app), the problem is not triggered.

When active, it seems that the condition can be cured without restarting voicecall-ui-prestart service simply by starting the Phone app manually. After this has been done once, the CPU usage settles to normal levels. Also the consequent switches of ambience do not trigger the bug anymore after launching the app once.

The bugged condition can be reproduced again by running systemctl --user restart voicecall-ui-prestart (or booting the phone), and then switching between the ambiences normally.

So this bug seems to be directly related to on how the ambience change process tries to operate with voicecall-ui when the latter hasn't previously been started by anything else than its preload service.