Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pure Maps does not close / finish navigation properly #31

Open
rinigus opened this issue Aug 30, 2018 · 12 comments
Open

Pure Maps does not close / finish navigation properly #31

rinigus opened this issue Aug 30, 2018 · 12 comments

Comments

@rinigus
Copy link
Owner

rinigus commented Aug 30, 2018

From TMO, https://talk.maemo.org/showpost.php?p=1545876&postcount=137 and https://talk.maemo.org/showpost.php?p=1547761&postcount=77

An even stranger thing happened about an hour later, when WhoGo was safely closed - or so I thought. I unlocked the phone for some other, unrelated reason, and it started speaking navigation instructions. I started WhoGo but it shut down instantly. I eventually had to restart Lipstick from Sailfish Utilities.

This has recently become the norm. Every time I use WhoGo for navigation, no matter how short, it always ends up like this. There was not a single time when it did not. I tried ending the navigation and clearing the route and all map markers before I close the application, but that seems to make zero difference. The GPS icon in the status bar is flashing and the battery drains about 4x faster than you would expect. Usually, unless I trigger this issue and the phone stays silent, I also get voice prompts even though no application is open.

I also found that restarting Lipstick is not enough. Only a complete reboot is. A reboot or power cycle every time after navigation has now become part of the experience. (This is on J1, but I have noticed at least one other user reporting a similar experience on the X.)

@Olf0
Copy link

Olf0 commented Aug 30, 2018

I experienced this, too.
The hint was, that other "memory hogs" (e.g. Firefox for Android) were unusable after a navigation with Pure Maps (having it closed before starting the other "big" app), unless the Jolla 1 was rebooted.
Yes, a simple lipstick restart was not sufficient to resolve this (tried that first).

@rinigus
Copy link
Owner Author

rinigus commented Sep 4, 2018

One way to impose this is to:

  • start OSM Scout Server
  • start Pure Maps
  • stop OSM Scout Server by killall -SIGSTOP harbour-osmscout-server
  • close Pure Maps

Observe that Pure Maps will be not stopped until killall -SIGCONT harbour-osmscout-server is issued.

So, at least one of the reasons: enforce closing of all connections at stop

rinigus added a commit that referenced this issue Sep 5, 2018
HTTP connections are done using blocking calls. These blocking calls could have rather long timeouts (10 min for offline server to ensure that it works on slow hardware and allows to handle hardware suspend to some limited extent) and could result in hanging application exit. By pushing HTTP connections into separate threads, the connections can be terminated with the program exit through thread termination. All idle connections are closed properly.
@Olf0
Copy link

Olf0 commented Dec 2, 2018

Mmmh, I observed this again with PureMaps 1.9.0 yesterday, but did not have the time to analyse what exactly happened.
I may try to reproduce and analyse this at around Christmas.

@rinigus
Copy link
Owner Author

rinigus commented Dec 2, 2018

I presume that you use latest Mapbox GL QML plugin. If not, please check with it. On my device (onyx), I haven't seen it for a very long time.

@Olf0
Copy link

Olf0 commented Dec 2, 2018

I presume that you use latest Mapbox GL QML plugin.

That (yesterday) occurred with mapbox-gl-qml v1.3.2 from OpenRepos.

@rinigus
Copy link
Owner Author

rinigus commented Dec 2, 2018

Yep, that's the latest. So my SSL fix is in already.

@rinigus
Copy link
Owner Author

rinigus commented Jan 10, 2019

@Olf0 - I presume this test slipped the proposed timeslot?

@Olf0
Copy link

Olf0 commented Jan 10, 2019

Thanks for the trigger, as it did not occur anymore, I completely forgot about it.

So explicitly testing it now:

  • Starting PureMaps
  • Checking per ps -elf | egrep 'scout|pure' that PureMaps and OSM Scout Server are running (= waiting until the map is displayed in PureMaps)
  • Testing:
    1. Closing PureMaps: O.K., OSM Scout Server keeps running (until the set timeout).
    2. kill -STOP <pid of OSM Scout Server>: O.K. (the test you suggested), PureMaps not running (per ps) after closing it at the GUI.
    3. Additionally tried the signals TERM (default), HUP and KILL: Also O.K. (OSM Scout Server is properly restarted, when waiting until the map is displayed after switching back to PureMaps to close it).

Summary: I have not experienced this anymore, plus I cannot reproduce it by testing (but note, that I never ran those tests before).

Thanks, I think this issue can be closed for good. :)

@rinigus
Copy link
Owner Author

rinigus commented Jan 11, 2019

Closing with pleasure and hoping it will not resurface :)

@rinigus rinigus closed this as completed Jan 11, 2019
@rinigus
Copy link
Owner Author

rinigus commented Jun 28, 2019

@rinigus
Copy link
Owner Author

rinigus commented Sep 29, 2019

Any new instances of that with the latest release?

@Olf0
Copy link

Olf0 commented Sep 29, 2019

I did not experience any since January 2019, as noted in my comment (2019-01-11) above.
But as it is just us (two) discussing here and the recent reports were posted at TMO (although 3 months ago), I wonder if it makes more sense to ask there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants