[4.4.0] mpris-proxy service crashing and not restarting

REGRESSION: Yes, worked in


mpris-proxy isn’t running by default. This leads into Bluetooth headset play/pause/prev/next buttons not working.


Deezer installed (Spotify should do, too) and a suitable Bluetooth device connected.


  • Start the music on the player
  • Click play/pause


  • Music stops


  • Music keeps playing


This worked fine with SFOS 4.2 on the same device, but stopped after updating to 4.3.


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.

1 Like

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 :frowning: Maybe can anybody port this app to aarch64 please?

my workaroud is to use ShellEx with the comand “mpris-proxy” and now it works for me…

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.

mpris-proxy should show as running with command systemctl status --user mpris-proxy.

I briefly tried to look out for the service, but couldn’t find it. Now that I did…

● mpris-proxy.service - Bluez5-MPRIS Proxy
Loaded: loaded (/usr/lib/systemd/user/mpris-proxy.service; disabled; vendor preset: enabled)
Active: failed (Result: core-dump) since Sun 2022-01-02 19:28:03 EET; 2 days ago
Process: 6329 ExecStart=/usr/bin/mpris-proxy (code=dumped, signal=ABRT)
Main PID: 6329 (code=dumped, signal=ABRT)

Well thay explains it!

Restarting it worked, which is nice :slight_smile:

Perhaps stopping Android App Support crashes it…? That’s the only odd thing I did two days ago…

I’ve pinged the author of BTons and added it to the update needed list, https://forum.sailfishos.org/t/apps-that-havent-been-ported-to-aarch64

I fear it will only add to the confusion to resurrect it.

1 Like

Thanks! The author of BTons has alerted me to same :slight_smile: My itchy trigger finger … chop, chop.


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 :slight_smile:

Nope, it didn’t help. I still have to restart the service every almost daily.

There is an ugly workaround however; see this post

I’ve been checking to see to what extent this is hardware dependant and the service remains up and functional on the yolla/GS290 phones:

[defaultuser@VollaPhone ~]$ systemctl status --user mpris-proxy
● mpris-proxy.service - Bluez5-MPRIS Proxy
   Loaded: loaded (/usr/lib/systemd/user/mpris-proxy.service; disabled; vendor preset: enabled)
   Active: active (running) since Sat 2022-01-08 15:28:04 CET; 1 weeks 1 days ago
 Main PID: 1945 (mpris-proxy)
   CGroup: /user.slice/user-100000.slice/user@100000.service/mpris-proxy.service
           └─1945 /usr/bin/mpris-proxy

I lost mpris-proxy again this weekend, and the reason is quite obvious:

$ systemctl --user status mpris-proxy
● mpris-proxy.service - Bluez5-MPRIS Proxy
   Loaded: loaded (/usr/lib/systemd/user/mpris-proxy.service; enabled; vendor preset: enabled)
   Active: failed (Result: core-dump) since Sat 2022-05-14 10:13:07 EEST; 2 days ago
  Process: 5934 ExecStart=/usr/bin/mpris-proxy (code=dumped, signal=SEGV)
 Main PID: 5934 (code=dumped, signal=SEGV)

Well, I think I figured out the obvious workaround: systemd --user edit mpris-proxy

Put the following lines in the editor:


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 :slight_smile:


Is this also present on 4.4?

Yes; the last two posts were about a X10II tunning 4.4.0.

Can you update the first post with that information?

I can’t edit the post anymore, it’s too old…

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”.