Reply
Thread Tools
Posts: 211 | Thanked: 62 times | Joined on Oct 2014 @ Finland
#91
Hello hhaveri.

I have sent email to pastillilabs. I wrote it in finnish, I hope that this is okay?

As short: It does not matter what situation is used, but it needs to be at least one situation in use.

If paused from no situation and unpausing back to no situation, it does not crash.

If you need more info, please let me know. And if you need some error log, please tell me how to find these logs

Best Regards,
Mikko
 
Schturman's Avatar
Posts: 5,339 | Thanked: 4,133 times | Joined on Jan 2010 @ Israel
#92
Hi to all.
I have a little problem with situations behavior when it should to use "sell id".
When I in the "sell id" area it should start my little app that activate wifi tethering and BT. But if my screen closed (black) Situations app not start my app, just doesn't do nothing even if I in the "sell id" areas.
Now, if I just open my screen wile driving in the "sell id" area, it trigger Situations app and it start my app (tethering and BT).
Can someone confirm same behavior ?
 
Posts: 211 | Thanked: 62 times | Joined on Oct 2014 @ Finland
#93
Originally Posted by Schturman View Post
Hi to all.
I have a little problem with situations behavior when it should to use "sell id".
When I in the "sell id" area it should start my little app that activate wifi tethering and BT. But if my screen closed (black) Situations app not start my app, just doesn't do nothing even if I in the "sell id" areas.
Now, if I just open my screen wile driving in the "sell id" area, it trigger Situations app and it start my app (tethering and BT).
Can someone confirm same behavior ?
Hi.

I have noticed sometimes similar info. It is just that I have cell id located in my home.

When I leave from the premises, then it does not activate it instantly, but when I "activate" my phone, then it changes the situation.

I am using next version of the app, but I havenīt tested, if this is still valid with the new one. (got this straight from pastillilabs) But crashing with pause - wait - unpause is not happening anymore
 

The Following User Says Thank You to R1v3r For This Useful Post:
Posts: 203 | Thanked: 596 times | Joined on Jan 2015 @ Finland
#94
Yes, there have been a couple similar reports. I guess the system (org.ofono) does not necessarily send any cell id updates while the device is sleeping. And one option to fix it would be to implement regular polling to the cell id condition as well. Shouldn't be too bad for battery, but still a bit worse.

Btw, submitted a fix for the crashing issue & BT accessory detection to Harbour today. So it might be available next week to all. But it's also the first time testing the sense of humor at Jolla with the availability of Location condition via the app (which uses an API not currently permitted in Harbour)
 

The Following 5 Users Say Thank You to hhaveri For This Useful Post:
Posts: 73 | Thanked: 16 times | Joined on May 2012 @ THESSALONIKI GREECE
#95
Hi guys.I have a problem with native camera app.Look screen shoot.How can reinstall camera app without factory reset?

With new update my camera work again.
Attached Images
 

Last edited by gaiosgf; 2015-03-04 at 12:27.
 
Posts: 51 | Thanked: 41 times | Joined on Feb 2015 @ Mansester, FI
#96
Originally Posted by hhaveri View Post
I guess the system (org.ofono) does not necessarily send any cell id updates while the device is sleeping. And one option to fix it would be to implement regular polling to the cell id condition as well. Shouldn't be too bad for battery, but still a bit worse.
I don't know how the polling could be technically implemented, but having for example a recurring timer to do it shouldn't IMO be that bad... After all, the polling interval doesn't really have to be that short, something every two minutes would be luxurious, and I could even live with update poll every ten minutes since with cell IDs its never that accurate anyway when the condition would fire.

As for the issues with cell IDs I've been talking about, I tried having a fresh start with Situations last weekend. Uninstalled, wiped the /home/nemo/.local/share/harbour-situations2application directory, reinstalled and reconfigured everything. I don't know why, but I still don't get the correct situation enabled when getting to the office. Our office has also been moved to another location so pretty much everything is fresh, except the rules, and the issues. Trying to record cell IDs doesn't produce anything.

Last two mornings I've needed to restart the GUI process to get it fixed (swipe from top, restart). However, if the background process is the one that should be taking care of executing the rules, I wonder why the GUI process interferes so badly with this...?

Anyway, the rule I seem to have issues with has two conditions:
  • time: 7:00-18:00 mo-fr
  • cell ID: belongs to the list
There are four actions in the rule:
  • profile: normal
  • ringer volume: very low
  • mobile data: on
  • wifi: off
 
Posts: 203 | Thanked: 596 times | Joined on Jan 2015 @ Finland
#97
Polling is easy to implement as such, but I'm not at all sure it is a good or correct way to solve the problem. Besides the interval, one should know how long to keep the device awake to get the cell id updated. If that as such even is a way to get it updated. Need to investigate more...

Next time you notice that recording cells does not do anything, could you try running the following command in Terminal:

dbus-send --system --print-reply --dest=org.ofono /ril_0 org.ofono.NetworkRegistration.GetProperties

It should print out some network info and is basically the way cell id is being read to the application.
 

The Following 2 Users Say Thank You to hhaveri For This Useful Post:
Posts: 51 | Thanked: 41 times | Joined on Feb 2015 @ Mansester, FI
#98
Originally Posted by hhaveri View Post
Next time you notice that recording cells does not do anything, could you try running the following command in Terminal:

dbus-send --system --print-reply --dest=org.ofono /ril_0 org.ofono.NetworkRegistration.GetProperties

It should print out some network info and is basically the way cell id is being read to the application.
Tried that now, got back info on the network but there's no cell ID present (returned entries are "Status", "Mode", "LocationAreaCode", "Technology", "MobileCountryCode", "MobileNetworkCode", "Name" and "Strength"). Even after killing the Situations GUI process there's no "CellID" entry, but when starting Situations GUI again and having the correct situation activated shortly after that, there's also "CellID" in the list of returned entries.

To me that only seems strange, but I do hope that it shines some light upon this issue
 
Posts: 203 | Thanked: 596 times | Joined on Jan 2015 @ Finland
#99
Originally Posted by zagrim View Post
Tried that now, got back info on the network but there's no cell ID present (returned entries are "Status", "Mode", "LocationAreaCode", "Technology", "MobileCountryCode", "MobileNetworkCode", "Name" and "Strength"). Even after killing the Situations GUI process there's no "CellID" entry, but when starting Situations GUI again and having the correct situation activated shortly after that, there's also "CellID" in the list of returned entries.

To me that only seems strange, but I do hope that it shines some light upon this issue
It does seem strange but also indicates that the problem is not at least directly in Situations app. Maybe it is a bug or just some weird logic in org.ofono or whoever is responsible for publishing the cell id there. Maybe it is somehow related to the mobile network properties. Maybe something else.

Can you try to repeat the experiment with Situations app completely disabled (to see if cell id is sometimes not returned)?
 

The Following User Says Thank You to hhaveri For This Useful Post:
Posts: 51 | Thanked: 41 times | Joined on Feb 2015 @ Mansester, FI
#100
Originally Posted by hhaveri View Post
Can you try to repeat the experiment with Situations app completely disabled (to see if cell id is sometimes not returned)?
I'd assume it would take a lot of luck to spot such a case by manual testing, even though this seems to reproduce itself rather reliably each morning... But what I could try, of course, is to code a shell script that could repeatedly try that command and see if CellID is returned or not. I could do that, no problem. Next thing I'll do, however, is to install SFOS update 11. Who knows if that might even fix this (assuming it is due to a bug which has been fixed in the platform)...
 

The Following User Says Thank You to zagrim For This Useful Post:
Reply

Tags
sailfish os, situations

Thread Tools

 
Forum Jump


All times are GMT. The time now is 08:09.