Reply
Thread Tools
Posts: 63 | Thanked: 106 times | Joined on Mar 2017
#81
Originally Posted by Flash-A-Holic View Post
My battery stuck to 100% (I took Droid off from the charger) and reboot won't fix it. This happened couple times before but reboot fixed it earlier, weird

Do you guys think that I need reflash? I didn't install any modifications before this issue. I'm on the latest 2.1.0.11 version.
Yeah, I get that too sometimes. I find that if I boot into another OS like Android, then go back to Sailfish it helps, though even then, I sometimes need to reboot again before it works. But with enough reboots, I can always get it to sort itself out without resorting to anything drastic.
However, I notice that when this problem occurs, Safestrap is also incorrectly reporting the battery level at 99% - I don't know what that implies?
Also, are you using the safe slot? I am, and I don't remember this problem happening when I used a virtual slot, but that might just be because I didn't use it very long in a virtual slot.
 

The Following User Says Thank You to moodroid For This Useful Post:
Posts: 23 | Thanked: 78 times | Joined on Sep 2016 @ Finland
#82
Originally Posted by moodroid View Post
Yeah, I get that too sometimes. I find that if I boot into another OS like Android, then go back to Sailfish it helps, though even then, I sometimes need to reboot again before it works. But with enough reboots, I can always get it to sort itself out without resorting to anything drastic.
However, I notice that when this problem occurs, Safestrap is also incorrectly reporting the battery level at 99% - I don't know what that implies?
Also, are you using the safe slot? I am, and I don't remember this problem happening when I used a virtual slot, but that might just be because I didn't use it very long in a virtual slot.
I'm using stock ROM slot and I don't have Android installed to my device right now. I think that I'm waiting for next build and then reflash Sailfish OS again.

I also noticed that Safestrap reports wrong battery status some times. That happened also when I had only Android installed. However Android always reported right battery-%.

EDIT: After several reboots battery-% is now working again.

Last edited by Flash-A-Holic; 2017-05-28 at 08:05.
 

The Following User Says Thank You to Flash-A-Holic For This Useful Post:
Posts: 63 | Thanked: 106 times | Joined on Mar 2017
#83
Does anyone else have a problem with incoming calls and sound? Outgoing calls work fine, but sometimes when I receive a call, I can't hear the other person, and then I lose sound altogether and have to reboot?
 

The Following User Says Thank You to moodroid For This Useful Post:
Posts: 194 | Thanked: 1,167 times | Joined on May 2016
#84
Originally Posted by moodroid View Post
However, I notice that when this problem occurs, Safestrap is also incorrectly reporting the battery level at 99% - I don't know what that implies?
Basically both Safestrap and SailfishOS report battery level they receive from kernel, so I'm not sure if this bug is SFOS port-specific. I wonder if Is there any battery calibration file normally loaded by Android.

Originally Posted by moodroid View Post
Does anyone else have a problem with incoming calls and sound? Outgoing calls work fine, but sometimes when I receive a call, I can't hear the other person, and then I lose sound altogether and have to reboot?
Could you please try to capture logs from journalctl when it happens? I suppose PulseAudio module crashes and won't restart for some reason.
 

The Following 2 Users Say Thank You to TheKit For This Useful Post:
Posts: 11 | Thanked: 15 times | Joined on Jun 2016 @ United States
#85
Originally Posted by Flash-A-Holic View Post
I'm using stock ROM slot and I don't have Android installed to my device right now.
It's generally considered a bad idea to have this on your stock slot, so that may be causing the issue.

Also I've not been able to get around to uploading my ofono log because of some issues IRL, but I might be able to sometime soon.

Do you guys think this would work for us? I'm fairly sure the Droid 4 would explode under all that stress, but who knows?

Last edited by ThePhxRises; 2017-06-03 at 01:41.
 

The Following 3 Users Say Thank You to ThePhxRises For This Useful Post:
Posts: 63 | Thanked: 106 times | Joined on Mar 2017
#86
Originally Posted by TheKit View Post
Could you please try to capture logs from journalctl when it happens? I suppose PulseAudio module crashes and won't restart for some reason.
After a bit more testing, it appears that the first incoming call usually works ok, but on the 2nd incoming call, I lose sound and have to reboot.
I've got the journalctl logs for the first incoming call (1.txt) which worked, and then the 2nd incoming call (2.txt) which didn't.
I can't understand why this only happens to me? I've tried a clean install and it's still the same, and I've even tried on my old Droid 4 (which is falling to bits) and it's the same on that too.
Are incoming calls really working fine for everyone else?

EDIT: I don't really know what I'm doing here, but have tried a few things in case they help...
In /etc/pulse/daemon.conf I've added:
log-target = file:/home/nemo/pa.log
log-level = debug

I then rebooted, and called myself, and on this occasion I lost sound on the first call (which happens sometimes). I've attached the pa.log that it created.
When I try pacmd, it says 'Daemon not responding.', so don't know if that means it's crashed?

EDIT2: Well, I've found that I can restart pulseaudio without rebooting by doing:

pkill -9 pulseaudio
pulseaudio -vvvv --start -n --file=/etc/pulse/arm_droid_default.pa

I've tried it in the foreground (without the --start), and when the problem occurs, it seems that the process doesn't abort, but just hangs?
D: [pulseaudio] module-suspend-on-idle.c: Sink sink.null becomes idle, timeout in 1 seconds.
D: [pulseaudio] policy-group.c: Starting to move sink input feedback-event
D: [pulseaudio] dbusif.c: Policy groups moving: 9
D: [pulseaudio] droid-sink.c: Sink set port to parking
I: [pulseaudio] sink.c: Changed port of sink 1 "sink.primary" to output-parking

Thanks
Attached Files
File Type: zip logs.zip (5.2 KB, 60 views)
File Type: zip pa.zip (14.9 KB, 57 views)

Last edited by moodroid; 2017-06-09 at 14:51.
 

The Following 3 Users Say Thank You to moodroid For This Useful Post:
Posts: 194 | Thanked: 1,167 times | Joined on May 2016
#87
Originally Posted by moodroid View Post
I've tried it in the foreground (without the --start), and when the problem occurs, it seems that the process doesn't abort, but just hangs?
This happens to me to, but have to find why yet. Do you know if it was always like this or started after 2.0.1.11 update?

Originally Posted by ThePhxRises View Post
Do you guys think this would work for us? I'm fairly sure the Droid 4 would explode under all that stress, but who knows?
It can, but it turned out a bit more tinkering is required. On our device, hwcomposer lib can be loaded only once, and it's already used by SFOS. AD doesn't use hwcomposer API directly, but it's still loaded to find proper graphics format by SurfaceFlinger, so OpenGL ES context selection fails and it won't start.

I tried to disassemble and patch libsurfaceflinger to select proper EGL context. It still didn't start, but after replacing OpenGL ES libs with the ones built from CyanogenMod 11 tree, it seems to be able to start apps like Telegram/Discord. Camera doesn't work though, and would probably require using shim library for missing symbols in libc.so.

Here are the changed files if anyone wants to try.
 

The Following 3 Users Say Thank You to TheKit For This Useful Post:
Posts: 63 | Thanked: 106 times | Joined on Mar 2017
#88
Originally Posted by TheKit View Post
This happens to me to, but have to find why yet. Do you know if it was always like this or started after 2.0.1.11 update?
Thanks. Glad it's not just me.

Just tried it on the first version that you did for us, and the same thing is happening. And I didn't apply the headphones kernel patch either, so it's nothing to do with that.

I'm happy to try anything out if I can help in any way..

Last edited by moodroid; 2017-06-11 at 09:56.
 

The Following 2 Users Say Thank You to moodroid For This Useful Post:
Posts: 63 | Thanked: 106 times | Joined on Mar 2017
#89
Originally Posted by TheKit View Post
This happens to me to, but have to find why yet. Do you know if it was always like this or started after 2.0.1.11 update?
As mentioned above, it's definitely always been been like this, but as I don't don't get that many incoming calls, and because I reboot quite often when fiddling with stuff, it took me a while to spot what was going on, sorry.

I've tried tweaking lots of pulseaudio settings, but haven't been able to influence this in any way. I also had the idea of killing and restarting pulseaudio after answering a call, to see if I could bring back audio during the call itself, but unfortunately, it only seems to work after the call has finished.

It occured to me that testing it might end up costing you money in calls, so if you ever wanted a donation, I'd be more than happy to oblige. No offence intended if you don't go in for that kind of thing - just thought I'd offer.

Or if there's any crazy alternatives like trying to use an alternative phone app (Android via AD or other Linux via chroot?), I'd be more than happy to give it a go if you thought it was even feasible.

Many thanks
 

The Following User Says Thank You to moodroid For This Useful Post:
Posts: 194 | Thanked: 1,167 times | Joined on May 2016
#90
Originally Posted by moodroid View Post
As mentioned above, it's definitely always been been like this, but as I don't don't get that many incoming calls, and because I reboot quite often when fiddling with stuff, it took me a while to spot what was going on, sorry.

I've tried tweaking lots of pulseaudio settings, but haven't been able to influence this in any way. I also had the idea of killing and restarting pulseaudio after answering a call, to see if I could bring back audio during the call itself, but unfortunately, it only seems to work after the call has finished.
Thanks for the reply. I was already able to pinpoint what is causing PulseAudio to freeze. It turned out our audio blob uses AudioSystem::getDeviceConnectionState for BT headset detection, which in turn is dependant on AudioPolicyService, not enabled in SFOS, so it waits for it forever.

As a quick hack, try placing patched libmedia.so to /usr/libexec/droid-hybris/system/lib (it won't wait for AudioPolicyService).

For the long term solution I'd better try to enable AudioPolicyService service, as it was done for onyx and probably some other devices. That patch doesn't built as-is with hybris-11 though.

And well, testing is not a problem, since phone network is pretty cheap in Russia (for example, I have 300 minutes, which I never manage to use considerable amount of, and 3 GB for about 3.3$/month).
 

The Following 5 Users Say Thank You to TheKit For This Useful Post:
Reply

Tags
droid, hwkbd, sailfish os, xt894

Thread Tools

 
Forum Jump


All times are GMT. The time now is 14:48.