REPRODUCIBILITY: 100%
BUILD ID = OS VERSION: 4.3.0.12 and 4.4.0.64
HARDWARE: X10II and X10III
UI LANGUAGE: Finnish
REGRESSION: Yes, worked in 4.2.0.21
DESCRIPTION:
mpris-proxy isn’t running by default. This leads into Bluetooth headset play/pause/prev/next buttons not working.
PRECONDITIONS:
Deezer installed (Spotify should do, too) and a suitable Bluetooth device connected.
STEPS TO REPRODUCE:
Start the music on the player
Click play/pause
EXPECTED RESULT:
Music stops
ACTUAL RESULT:
Music keeps playing
ADDITIONAL INFORMATION:
This worked fine with SFOS 4.2 on the same device, but stopped after updating to 4.3.
WORKAROUND
Install and open a terminal and launch mpris-proxy. It stays on the foreground, so you’ll have to keep the terminal open. Now all the controls work as expected.
Alternatively, if you have developer mode enabled, a more convenient way is to install screen and run mpris-proxy there, and then C-a d to detach it. The terminal can then be closed.
I have test it with my new Sony Xperia 10ii with new installed SFOS 4.3 + Nokia Headset BH-505 and I have follow resoulds. With the jolla player it is possible to jump to the next sound but with tafelfish or AIMP (android app) its not possible. With Amazfish its possible for all apps. In the past I used the app BTtons but this is not ported to aarm64 Maybe can anybody port this app to aarch64 please?
Haven’t experienced an issue like this on XA2. Not sure if it will help, but I might suggest using Unplayer instead of the included Music app (I honestly uninstalled Music because tracker-minerFS just adds any and every MP3 to it. Intermittent sound effects and audiobooks do not go well when trying to just listen to your library on shuffle).
Just curious of it, I started checking systemctl to see if this was being handled by an existing service, but nothing seems to show up in that regard. I also checked journalctl but saw nothing where mpris-proxy shows up. My XB700s simply show up as udev inputs.
Also, the service is marked as disabled… I guess some other process could start it, but I flipped it to enabled. Let’s see what happens in the next reboot
Well, I think I figured out the obvious workaround: systemd --user edit mpris-proxy
Put the following lines in the editor:
[Service]
Restart=always
RestartSec=10s
After that the service restarted itself (after having segfaulted two days ago) as expected! Now, this causes the service to always restart, even in the case of OOM, but I think with its 0.1% memory usage it’s small enough to fly under the radar
And, sadly, this is still reproducible on X10III with the 6GB of RAM it has. Browser, Firefox, Deezer, Email, Whisperfish have been killed in action so far, and keeping an eye of htop suggests that OOM is the cause…
I try to fiddle with swappiness and friends, perhaps it just needs more aggreasive memory management.
Thanks for the report @direc85, and for digging deeper into the reasons. I’ve amended your original report with the new info (new title, 10III, 4.4.0) for clarity.
I’ve also created an internal bug report, so this is now tagged as “tracked”.