¯\(ツ)/¯
I fear it will only add to the confusion to resurrect it.
1 Like
Thanks! The author of BTons has alerted me to same 
My itchy trigger finger … chop, chop.
2 Likes
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
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
1 Like
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:
[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
6 Likes
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.
1 Like
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”.
4 Likes
Xperia 10 II with 4.4 installed from scratch doesn’t have this command.
@direc85 Do you know which package I need?
Whoops, that should be systemctl instead. Sorry about that!
1 Like
As a follow-up on this, the following change (following @direc85’s suggestion) has been made to prevent this from causing problems:
This will hopefully make it in to the next release, so I’ve tagged the topic as “fixed”.
2 Likes
The situation with this is worse with 4.4.0.72 than before. I have lowered the oom memory limits as with the previous dot release, but it mpris_proxy.service still gets sniped. I manually edited the pull request in and it seems to work as expected. It’s only a mitigation, though…
Anyone else with the same experience with 4.4.0.72 (w.r.t. 4.4.0.6x) specifically?
X10II 4.4.0.72 (III is still sitting on shelf, waiting for 4.5)
Wow, so this was all along why my phone has been intermittently struggling to play A2DP audio on car head unit.
Fairly certain I’ve been struggling with this over a year now, ever since I swapped head units in my car (order date reads Oct '21), and got BT A2DP capability to it.
Fresh off Sailfish reboot, BT would connect and play A2DP music fine on Spotify.
It always felt like with all the OOMs Sailfish app suffers through a session, somehow phone’s Bluetooth capability deteriorated, but I could never figure out the details. Next ride, BT connects fine, but head unit audio player fails to play audio or display track info, and no on-screen controls work.
Turns out I was always looking in the wrong place, trying to journalctl through bluetooth unit.
Yep, systemctl --user status mpris-proxy had crashed with SIGABRT, just like [4.4.0] mpris-proxy service crashing and not restarting - #6 by direc85 shows.
Yep, systemctl --user restart mpris-proxy immediately restored all functionality (I also edited service unit for auto-restart), and ended this year-long frustration that made me want to test other head units and go through all that rebuild trouble.
Got a couple of long drives coming up, couldn’t be happier about getting ths figured out. You the man @direc85.
PS phone doesn’t seem to have coredumpctl so we can’t really get details on why mpris-proxy crashes?
PPS History for tools/mpris-proxy.c - bluez/bluez · GitHub for History, hopefully it becomes hardened upstream.
2 Likes
4.5 update: something with mpris-proxy keeps crashing on initial connection to my car head unit.
Once it’s done crashing a few times, it’s able to reconnect and play perfectly. Tiresome, but looks like another log gathering mission ahead 
From Enable systemd-coredump I’ve discovered crash-reporter and managed to install it via simple # pkcon install crash-reporter.
Let’s see if I can actually manage to get an mpris-proxy crash report out of this 