Compare with my issues with XA2 (before it died).
This issue remains after the Update to 4.2 (EA) on my X 10 II.
I can confirm this (Xperia 10 ii, SFOS 4.2)
That’s bad, because it is very annoying to wait one minute after every call to make a new call, write a message or browsing the web…
Can someone with trustlevel 3 edit the tags of my bugreport from 4.0.1. to 4.1.0. please?
Thank you.
Replying here instead of creating a separate issue: For me 2G is completely broken. I can’t use the 2G only mode, which may also explain the network issues after a call. It just tries to connect and fail in a loop. I made a short video demonstrating the issue: cloud@neko.dev
This is on an Xperia 10 II, with 4.2.0.19.
The Ubuntu Touch guys seem to have the same issue (they use the mer ofono too) and one of them shared the following workaround:
We can fix the problem with adding the precise hidl interface: transport=binder:name=slot1;interface=radio@1.1 in the ril-subscription.conf file
I have filed an internal bug on this. Thanks for reporting.
Unfortunately the bug still exists in 4.2.0.21 EA on my Xperia 10 II.
Indeed, it takes almost exactly 150 seconds (2,5 minutes) to reconnect (SFOS 4.2.0.21, Xperia 10 ii, Telekom Germany). That is way too long.
Incoming call causes switching from 4G to 2G and thus cuts mobile internet. Once the call is finished, reestablishing a data connection with 2G takes more than a minute. However, the 2G data connection is automatically cut after a few seconds and for little less than 1,5 minutes no network access at all exists. Only thereafter 4G is back.
I’ve been able to send some Video and Logs of that to Jolla. Also I detected, that this only happens to me if WiFi is off. Reproducible. What i didn’t test, is the condition that WiFi is on but no network available. Perhaps someone can confirm that as well.
By the way, i think mine connects back in like in 36 sec or so.
Indeed, in my test I switched Wifi off. Reconnection depends on the quality of the mobile network. In our office the network is weak. This could be the reason why restoring mobile data connection took so long.
However, the steps are always the same: falling back to 2G for a voice call, after the call reestablishing a first data connection with 2G, then killing all mobile network access completly and eventually establishing a new 4G connection.
Unfortunately, this bug is still present in SFOS 4.3.0.12
The problem still occurs when mobile data is on and no WIFI is available.
Because of the last posts in this tread and the 3rd software version of SFOS 4 for Xperia 10II, I tested my t-mobile Germany SIM card again in the XperiaX.
The result:
In SFOS 4.1.0.24, 4.2.0.19 and 4.3.0.12 the SIM card works perfectly in the XperiaX. When a call is made, the network switches from 4G to 2G and after the call back to 4G without delay and without interrupting the mobile network.
The same SIM card shows the bug described above in the Xperia 10 II (aarch64) in all three SFOS versions.
Note: The 3G network of t-mobile Germany has been switched off since 1 July 2021.
Add it to the list of bugs for me which is just making be super frustrated at my phone.
X10i, latest update.
Glad you made this observation because it could help finding the true reason for the annoyingly long network pause after each call.
It is about the same time when I got my Xperia 10ii and t-mobile canceled 3G. Therefore I might have wrongly assigned the long network loss after every call to the switching-off of 3G - and not to SFOS/aarch64. I will check with my older back-up XA2 in order to confirm your observation
This annoying bug still exists in SFOS 4.4.0.58 EA. It is exasperating…
Yes, it is annoying. On my XA2 Plus I have also no Internet/Data Connection during the calls.
Five days ago I tried to fix this bug by flashing the phone with Android 11. I used it for a day, making and receiving calls. Both to different mobile providers and to landlines.
I sent and received text messages and surfed the internet.
Then I flashed SFOS 4.4.0.58. Unfortunately without result, the bug is still present.
@flypig Why have you tagged this bug report as fixed?
Have you fixed this internally and will we get it with the next OS update?
The bug is still present in SFOS 4.4.0.58.
Hi @silta, Thanks for pinging me about this: I’m glad you’re on the ball keeping track of things.
The community bug coordination team is cleaning up the bugs in the forum, and one of the steps has involved tagging all bugs that are noted in the release notes as having been fixed. There are over a hundred bugs like this, so there’s always a risk we make a mistake in the process.
In this case, this bug was reported as fixed in the release notes for Sailfish OS 4.2.0 Verla (it’s the very last bug in the list there).
Looking through our internal database, a number of changes were made to fix this issue, the decisive one being this change.
However, clearly you’re still experiencing problems.
It’d be really helpful to know whether the problems you’re experiencing now are identical to the ones you describe in your original bug report, or whether there have been any changes resulting from the fixes that have gone in?