3G connection is not an issue here - fir one, 3G connection is not active on Jolla, and second, I never had a problem connecting to my GMX.DE account over 3G with my N900.
Well I can't say if it's a bug or not but it worked on my N9 but it does not work on Jolla.
If you start typing a text message to a person but then leave it and begin typing another text to a different person the written text would stay. Now with Jolla if you don't send the text off and switch to read or write someone else your all of your written text will be gone
N9 kept the typed in text even if you turned off or rebooted the phone.
Any news on when Jolla is opening together.jolla.com portal?
@VDVsx
May be it was already reported, but I want to confirm it then: email client syncing is sporadic. I use 2 IMAP accounts and one Exchange. Exchange set to "Always up to date", IMAP to 5 minutes update period. I can see a mail is received in my Exchange account on my N9 and laptop at the same time, but not on Jolla. All devices connected to same Wi-Fi network. Also IMAP accounts are NOT updated every 5 minutes, but some (it seems)random periods.
PS. My device is ALWAYS connected be to mobile or Wi-Fi network.
@VDVsx
May be it was already reported, but I want to confirm it then: email client syncing is sporadic. I use 2 IMAP accounts and one Exchange. Exchange set to "Always up to date", IMAP to 5 minutes update period. I can see a mail is received in my Exchange account on my N9 and laptop at the same time, but not on Jolla. All devices connected to same Wi-Fi network. Also IMAP accounts are NOT updated every 5 minutes, but some (it seems)random periods.
PS. My device is ALWAYS connected be to mobile or Wi-Fi network.
IMAP is a know issue, it's related to align timers to save battery.
Exchange in "Always up to date" should work fine when inside the peak time and peak days, is that a standard Exchange or some third-party implementation(Zimbra, google apps for business, ...) ?
IMAP is a know issue, it's related to align timers to save battery.
There's definitely something funny going on with timers, as the command-line sleep utility seems to sleep much longer than intended, especially if the device is saving power. Verifying with perl sleep:
# perl -e 'printf("%d\n", sleep(10));'
117
i.e. a 10 second sleep took 117 seconds of wall clock time. This after disabling tohd to save power. I began to wonder about this when powertop runs never seemed to finish, or even start (preceded by sleep 120...)
EDIT: when the system is not idle (i.e. interactive and screen is on), the sleep timing seems to be accurate to the second. However, it starts to be off as soon as the screen goes dark.
Started and completed while the screen is interactive:
# perl -e 'printf("%d\n", sleep(10));'
10
Started one second (=reaction time) after the screen goes dark:
# perl -e 'printf("%d\n", sleep(10));'
17
@VDVsx
It is MS Exchange server.
As matter of fact approx. 1 hour ago it stopped syncing on Jolla. It was working OK on N9 and N900 in the same time. Disabling=>Enabling the account solved it.
There's definitely something funny going on with timers, as the command-line sleep utility seems to sleep much longer than intended, especially if the device is saving power.
When the device is in deep suspend, nothing is actually running. Things dealing with sync (for instance) wake the device up from suspend, as does network activity, alarms, and so on.
When the device is in deep suspend, nothing is actually running. Things dealing with sync (for instance) wake the device up from suspend, as does network activity, alarms, and so on.
OK, so the perl and bash sleep functions aren't built to wake the system from deep suspend.
As I asked in the other thread: Powertop suggests enabling Power Aware CPU scheduler, echo '1' > '/sys/devices/system/cpu/sched_mc_power_savings' - do you think that would make any difference?
There's definitely something funny going on with timers, as the command-line sleep utility seems to sleep much longer than intended, especially if the device is saving power. Verifying with perl sleep:
# perl -e 'printf("%d\n", sleep(10));'
117
i.e. a 10 second sleep took 117 seconds of wall clock time. This after disabling tohd to save power. I began to wonder about this when powertop runs never seemed to finish, or even start (preceded by sleep 120...)
While suspended timers like sleep is suspended too. If you want to make software that does something while suspended, you should use https://github.com/nemomobile/libiphb as that is currently the only thing which periodically can be used to wake from suspend. In the future we might offer somekind of Qt/QML API, bug no eta avail currently.
Having said that, please avoid using that, as we really want to save power and not have too many apps waking up from suspend periodically
