Notices


Reply
Thread Tools
Posts: 71 | Thanked: 135 times | Joined on Dec 2015 @ Spain
#331
Really impressed in how this offline map application works in sfos. Without doubt, one of the best solution in mobile offline navigation out there. Thanks!
 

The Following 5 Users Say Thank You to ferlanero For This Useful Post:
karlos devel's Avatar
Posts: 72 | Thanked: 177 times | Joined on Mar 2013 @ Guatemala
#332
A tons of Thanks to @rinigus of this.
__________________
Caballlero
 

The Following 3 Users Say Thank You to karlos devel For This Useful Post:
Posts: 347 | Thanked: 1,543 times | Joined on Aug 2016 @ Estonia
#333
I have released a new version with the changes by @mal: fixed typos found by him as well as updated his Finnish translation. Thank you @mal!

I wonder if there is someone around interested in linguistics or able to spell out pronunciation of some words. Namely, Valhalla supports US English (Pirate version) for its instructions. While a joke, its a nice one and, I think, very appropriate for Sailfish. Unfortunately, TTS software does not know how to pronounce "Arrr" and few other words. What TTS software can do, is to pronounce according to given phoneme description.

So, I would like to ask for help and maybe someone here can propose their versions for words listed at https://github.com/valhalla/valhalla/issues/891 .

In Sailfish, install mimic from OpenRepos ( https://openrepos.net/content/rinigus/mimic ) and use

Code:
mimic -voice awb -ssml -t 'Some <phoneme ph="k ae p n">Capn</phoneme> wheel' -o /tmp/out.wav && gst-launch-1.0 -q filesrc location=/tmp/out.wav ! wavparse ! pulsesink
to test the phonemes.
 

The Following 7 Users Say Thank You to rinigus For This Useful Post:
Posts: 173 | Thanked: 762 times | Joined on Dec 2014 @ Earth
#334
Originally Posted by rinigus View Post
After that I will continue the development according to suggestions and some ideas that I have. Right now, it has been suggested to allow using the server as a proper daemon.
The best way to be compatible with the official Jolla shop ("no daemon allowed" rule) and end-users desire (background daemon), while avoiding to have 2 completely different codepaths, would be :

- always run the server in a separate process
- (which also means : design some inter-process communication. DBUS ? simple webservice ? protocole buffers ?)
- give the ability to start only that process ("OSMScout --daemon" or something)

- for the version available on openrepos.net :
pack a systemd ".service" file that only start the daemon in background

- for the version avaiable on the shop :
don't pack that file.

When UI starts, it checks (see the IPC mentionned above) if there's a daemon process answering.
If not, it launches the daemon as a child process / as just another thread of the main UI task.

On the official version it means that the service will only be available while the UI is running (even if it uses a weird IPC instead of directly calling functions).

On the openrepos version, people have the possibility to launch the daemon in background at boot ("systemctl enable OSMscout.service") and only launch the UI to monitor daemon activity.
 

The Following 5 Users Say Thank You to DrYak For This Useful Post:
Posts: 347 | Thanked: 1,543 times | Joined on Aug 2016 @ Estonia
#335
Originally Posted by DrYak View Post
The best way to be compatible with the official Jolla shop ("no daemon allowed" rule) and end-users desire (background daemon), while avoiding to have 2 completely different codepaths, would be :

- always run the server in a separate process
- (which also means : design some inter-process communication. DBUS ? simple webservice ? protocole buffers ?)
- give the ability to start only that process ("OSMScout --daemon" or something)

- for the version available on openrepos.net :
pack a systemd ".service" file that only start the daemon in background

- for the version avaiable on the shop :
don't pack that file.

When UI starts, it checks (see the IPC mentionned above) if there's a daemon process answering.
If not, it launches the daemon as a child process / as just another thread of the main UI task.

On the official version it means that the service will only be available while the UI is running (even if it uses a weird IPC instead of directly calling functions).

On the openrepos version, people have the possibility to launch the daemon in background at boot ("systemctl enable OSMscout.service") and only launch the UI to monitor daemon activity.
Indeed, that would be a proper way of doing it. Would have to move all communication between GUI and the server to RPC then. Not too easy since it requires some redesign, but possible. I have added your suggestions to the corresponding github issue and let's see when I will get to that.

Alternative to RPC would be to add a command line switch and make some lock file. When user starts GUI, I can kill the daemon and run as GUI app. When GUI app is closed, a new daemon can be started as well. I would have to think how to ensure that its all working
 

The Following 6 Users Say Thank You to rinigus For This Useful Post:
Posts: 347 | Thanked: 1,543 times | Joined on Aug 2016 @ Estonia
#336
I just released a bugfix release that handles better tile requests coming with the out-of-bounds indexes. In addition, all maps have been updated and uploaded to the data.modrana.org server. Please let me know if there are any issues with the maps or otherwise.
 

The Following 10 Users Say Thank You to rinigus For This Useful Post:
seiichiro0185's Avatar
Posts: 250 | Thanked: 499 times | Joined on Nov 2007 @ Leipzig/Germany
#337
Another idea for running the server in the background would be to use Systemd Socket Activation, this way the Server would autostart if it is needed (=if a Request comes in), and could stop after a certain time of idle.
This way it would not be neccessary to waste resources if nothing is using the server, but activation would be transparent to any client app.
This would of corse imply that some proper IPC Mechanism is in place, because I don't think the "stop/start when GUI is launched" would work too well with that
__________________
N800 -> N810 -> N900 -> N9 -> Jolla & TOHKBD -> Jolla C -> Xperia X F5122 (SFOS X)

http://www.seiichiro0185.org

Last edited by seiichiro0185; 2017-08-21 at 08:22.
 

The Following 7 Users Say Thank You to seiichiro0185 For This Useful Post:
Posts: 347 | Thanked: 1,543 times | Joined on Aug 2016 @ Estonia
#338
Originally Posted by seiichiro0185 View Post
Another idea for running the server in the background would be to use Systemd Socket Activation, this way the Server would autostart if it is needed (=if a Request comes in), and could stop after a certain time of idle.
This way it would not be neccessary to waste resources if nothing is using the server, but activation would be transparent to any client app.
This would of corse imply that some proper IPC Mechanism is in place, because I don't think the "stop/start when GUI is launched" would work too well with that
I have never used it, have to read up on socket activation. However, from the brief look into intro blogs on it, it seems that the server code will have to be modified to accept the socket activated call. There are also questions on how to mix it with gui-started and socket-started options. Ideally, I don't want to modify the code too much and add additional split between worker and gui server threads connected via some RPC. But I'll read about this socket activation option and maybe its a solution. Seems that libmicrohttpd used in the server has some options to support it too, which is a good start.
 

The Following 7 Users Say Thank You to rinigus For This Useful Post:
Posts: 347 | Thanked: 1,543 times | Joined on Aug 2016 @ Estonia
#339
@seiichiro0185, I looked into it and probably, that's a proper way to do it. Such socket activation would need a bit of code, but, at least on the paper, it doesn't seem to be anything excessive. I might be able to work around shared port by using start/stop - this would need some testing though. I am finishing up the things that I started on client side and would look into daemon mode as soon as I be ready for it (probably would start working on it by the end of this week, if all goes to the plan).
 

The Following 8 Users Say Thank You to rinigus For This Useful Post:
Posts: 347 | Thanked: 1,543 times | Joined on Aug 2016 @ Estonia
#340
I have just uploaded 1.1.0 release.

This release adds automatic activation by systemd sockets. Thank you all for suggesting daemon mode and, in particular, @seiichiro0185 for the way to implement it. In this case, systemd's socket activation works very well and allows us to have minimal resources allocated for the server when we don't use it.

The server supports GUI and socket-activated modes. When you open the GUI, it stops the service and socket activation, waits till the server's ports get free, and works as usual. On closing GUI, socket activation is started again. If the server is started via socket activation, it runs in the background (no GUI) and would stop itself after some period of time when noone was accessing it (idle period can be set in settings).

Notice that if you access the server while switching between GUI and socket activation modes, you may get some requests ignored/dropped. This is a side effect of the implementation allowing me to avoid larger rewrite of the code. In practice, I have not seen such effect on my phone (OPX).

Enjoy using it and let me know if there are issues. The update is available via OBS, OpenRepos, and was submitted to the Harbour.
 

The Following 15 Users Say Thank You to rinigus For This Useful Post:
Reply

Tags
offline maps, sailfish os

Thread Tools

 
Forum Jump


All times are GMT. The time now is 04:15.