Did you try this one? I’m interested if it happens with this work around or not. The automated solution seems to be at the end of the discussion
[31 Mar]
I can advise a temporary solution, although it has become permanent for me, moving from version to version, which I use myself https://forum.sailfishos.org/t/the-sounds-of-incoming-calls-sms-notifications-disappear/9496/17?u=comsorg
Interestingly enough, I haven’t had this issue for quite some time (several weeks now), could some OS update have fixed it? I’m currently running 4.5.0.24
In my case I see a temporal correlation between the no sound issue and the removal of patch manager. I removed patch manager 5 days ago and still have sound. Before I had to restart once a day. Maybe this is another problem. Anyway, what I noticed further is that when the Issue occurs, it is even not possible to play music files. The start button is grayed out. Anybody seen this before?
EDIT: I have take back the part with patch manager - there is correlation. Just realized, that it happened again. And it is possible to play music files (without sound). It just takes like 10 seconds to play one second in the music player. The same applies for Videos. It’s like slow motion (without sound).
EDIT2: Please ignore my post… Here we are: [4.4.0.64][Xperia 10 III] The sound disappears and video freeze
I just spent a long weekend on the Åland Islands, and there I had to reset the phone (Sony Xperia 10 III, with SFOS 4.5.0.25) at least daily because the sounds had stopped working. Returning to mainland Finland and the capital region, I’ve not had this happen again.
Perhaps this long-standing issue is somehow related to bad radio fields and/or roaming (for some reason, Ålcom is tagged as being a roamed network, in spite of fully supporting Elisa clients at base prices)?
I also now realized that my hotel was right by the harbour, and ships (with their own mobile base stations) coming and going on a regular basis might have something to do with this.
Did you use (android) map application during the trip? Those are usually memory hungry and cause oom-events which may ruin ngdf functionality.
Yes, I did use c:geo (although it is rather conservative with memory usage, pre-loading the National Survey map makes it rather huge in any case).
I got this bad behaviour due to Android TEAMS app.
When my status was set on computer as “do not disturb” it silenced all my devices and apps (included smartphone)
Solved by checking personal accounts “current status” to be not “silenced”
Unfortunately this issue seems to persist even in SFOS 4.6.0.11 (Sauna), last night during Jolla Love Day 2 I upgraded, and a couple of hours later I noticed that my sounds were gone. Resolved with the usual reboot.
For some reason I’ve now within a few days been repeatedly been hit by this issue under SFOS 4.6.0.15 (Sauna), and in a way that restarting the audio system did not help. Rebooting did.
systemctl --user restart ngfd works for me, but overall this problem seems relates to gstreams problem and is long existing somehow, normal audio player doesn’t have any problem but just notifications does cause this bugs sporatically
I haven’t had problems for months, then in the last few days I had to restart ngfd several times…
I can now reliably reproduce it using this simple script below.
A freshly started ngfd will die at the third or fourth invocation of it.
Note that it seems to be dependent on the type of “VIBRA_ID” (category form /usr/share/ngfd/events.d/
#!/usr/bin/python3
import dbus
# ‣ Type=method_call Endian=l Flags=0 Version=1 Priority=0 Cookie=2209
# Sender=:1.9557 Destination=com.nokia.NonGraphicFeedback1.Backend Path=/com/nokia/NonGraphicFeedback1 Interface=com.nokia.NonGraphicFeedback1 Member=Play
# UniqueName=:1.9557
# MESSAGE "sa{sv}" {
# STRING "pulldown_highlight";
# ARRAY "{sv}" {
# };
# };
DEST="com.nokia.NonGraphicFeedback1.Backend"
PATH="/com/nokia/NonGraphicFeedback1"
IFACE="com.nokia.NonGraphicFeedback1"
#METHOD="Play
#VIBRA_ID="pulldown_highlight"
#VIBRA_ID="pulldown_lock"
VIBRA_ID="feedback_alert"
#get the session bus
bus = dbus.SystemBus()
the_object = bus.get_object( DEST, PATH )
the_interface = dbus.Interface(the_object, dbus_interface=IFACE)
asv = dbus.Array()
print("Sending:", VIBRA_ID)
reply = the_interface.Play(VIBRA_ID, asv, signature="sa(sv)")
print("Got:", reply)
#reply = the_interface.Stop(reply)
Running
while sleep 0.5 ; do time ~/bin/vibrate_dbus.py || break; done
will either hang, or crash ngfd.
Awesome! I will try this on the Mi note 10. I guess you have these results on C2, right?
Adding to the ping list: @pvuorela as he was recently looking into this too ,
Thanks, I will definitely poke around running that script! We are aware that ngfd still needs work; let’s hope this helps luring the underlaying bug out.
Same principle, simpler call:
while sleep 0.5; do
busctl call com.nokia.NonGraphicFeedback1.Backend / com.nokia.NonGraphicFeedback1 Play 'sa(sv)' feedback_alert 0
done
BTW, ngfd tag 1.4.5 behaves the same. I’m looking at a C2 device.
I can see two different segfaults, sometimes it’s one, sometimes the other. I also have seen a SIGBUS error instead of the segfault, but can’t reproduce that one.
Backtrace after issuing:
busctl --quiet call com.nokia.NonGraphicFeedback1.Backend / com.nokia.NonGraphicFeedback1 Play 'sa(sv)' email 0
Thread 1 "ngfd" received signal SIGSEGV, Segmentation fault.
0x000000761e4eff7c in g_hash_table_lookup () from /usr/lib64/libglib-2.0.so.0
(gdb) backtrace
#0 0x000000761e4eff7c in g_hash_table_lookup () from /usr/lib64/libglib-2.0.so.0
#1 0x000000000040bbc0 in n_proplist_get (key=<optimized out>, proplist=0xd023010) at proplist.c:223
#2 n_proplist_get_pointer (proplist=proplist@entry=0xd023010, key=key@entry=0x761de7ce60 "dbus.event.client") at proplist.c:358
#3 0x000000761de7b250 in dbusif_send_reply (iface=<optimized out>, request=<optimized out>, code=1) at plugin.c:825
#4 0x000000000040a630 in n_core_request_done_cb (userdata=0xd20d9a0) at core-player.c:355
#5 0x000000761e5013c4 in ?? () from /usr/lib64/libglib-2.0.so.0
#6 0x000000761e504648 in ?? () from /usr/lib64/libglib-2.0.so.0
#7 0x000000761e5050b0 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#8 0x0000000000406838 in main (argc=<optimized out>, argv=0x7feb79a0d8) at main.c:204
Thread 1 "ngfd" received signal SIGSEGV, Segmentation fault.
0x000000000040a5d8 in n_core_stop_sinks (request=0x615e60, sinks=<optimized out>) at core-player.c:259
259 if (sink && sink->funcs.stop)
(gdb) backtrace
#0 0x000000000040a5d8 in n_core_stop_sinks (request=0x615e60, sinks=<optimized out>) at core-player.c:259
#1 n_core_request_done_cb (userdata=0x615e60) at core-player.c:339
#2 0x0000007ff7de13c4 in ?? () from /usr/lib64/libglib-2.0.so.0
#3 0x0000007ff7de4648 in ?? () from /usr/lib64/libglib-2.0.so.0
#4 0x0000007ff7de50b0 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#5 0x0000000000406838 in main (argc=<optimized out>, argv=0x7ffffff258) at main.c:204
Aha, finally got the BUS Error as well. Run with -vvvvvvvv. Note the garbage at request->name!
[13.18446744073709550725] DEBUG: ffmemless: prepare
[13.18446744073709550725] DEBUG: ffmemless: prep effect message, repeat 2 times, duration of 760 ms
[13.18446744073709550725] DEBUG: core: sink 'ffmemless' synchronized for request 'email'
[13.18446744073709550725] DEBUG: core: all sinks have been synchronized
[13.18446744073709550725] DEBUG: dbus: sending reply for request 'email' (event.id=1) with code 2
[13.18446744073709550725] DEBUG: ffmemless: play
[13.18446744073709550725] DEBUG: ffmemless: play id 11, repeat 2 times, iface 0x486b40, req 0x616110 data 0x619090
[13.18446744073709550725] DEBUG: ffmemless: setting up completion timer
[13.18446744073709550725] DEBUG: ffmemless: Starting playback 11
[13.18446744073709550727] INFO: dbus: >> client disconnect (:1.10877)
[13.18446744073709550727] DEBUG: core: stopping all sinks for request 'email'
[13.18446744073709550728] DEBUG: ffmemless: stop
[13.18446744073709550728] DEBUG: ffmemless: Effect id 11 completed
[13.18446744073709550728] DEBUG: core: sink 'ffmemless' completed request 'email'
[13.18446744073709550728] DEBUG: core: all sinks have been completed
[13.18446744073709550728] DEBUG: ffmemless: Stopping playback 11
[13.18446744073709550728] DEBUG: dbus: sending reply for request 'email' (event.id=1) with code 1
[13.18446744073709550728] DEBUG: core: request 'email' done
[13.18446744073709550728] DEBUG: core: stopping all sinks for request '� ^'
Thread 1 "ngfd" received signal SIGBUS, Bus error.
0x0068732f7273752f in ?? ()
(gdb) backtrace
#0 0x0068732f7273752f in ?? ()
#1 0x000000000040a5e4 in n_core_stop_sinks (request=0x616110, sinks=<optimized out>) at core-player.c:260
#2 n_core_request_done_cb (userdata=0x616110) at core-player.c:339
#3 0x0000007ff7de13c4 in ?? () from /usr/lib64/libglib-2.0.so.0
#4 0x0000007ff7de4648 in ?? () from /usr/lib64/libglib-2.0.so.0
#5 0x0000007ff7de50b0 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#6 0x0000000000406838 in main (argc=<optimized out>, argv=0x7ffffff248) at main.c:204
Looking at these three lines.
the code has:
321 static gboolean
322 n_core_request_done_cb (gpointer userdata)
323 {
324 NRequest *request = (NRequest*) userdata;
[...]
335 request->stop_source_id = 0;
336 core->requests = g_list_remove (core->requests, request);
337
338 N_DEBUG (LOG_CAT "stopping all sinks for request '%s'", request->name);
339 n_core_stop_sinks (request->stop_list, request);
340
[...]
388 done:
389 /* free the actual request */
390 N_DEBUG (LOG_CAT "request '%s' done", request->name);
391 n_request_free (request);
392
393 return FALSE;
394 }
So why do we get
core: request 'email' done
before
DEBUG: core: stopping all sinks for request '� ^'?
If I read this correctly, request is already freed after the ‘done’ message?
Nice investigations here! I think I’ve found something on the code side.
Could help with the crash:
Not sure how much that helps the original problem, though. No sounds can be more likely ngfd stuck. Also the regression related to the PR was introduced after this bug report.
Cool thing, it does! It makes all my known reproducers not reproduce any more.
I believe the hang (not crash) occurs through
339 n_core_stop_sinks (request->stop_list, request);`
in
260 sink->funcs.stop (sink, request);
in in the random case the deleted request does not cause a segfault elsewhere.