Notices

Well, I remember when i first moved to timeline engine and my phone got rebooted I've received a bunch of empty messages with [Action] action - which at that moment I thought was bound to certain mistype in platform integration.
Since then I never got it again (neither normally nor on reboot) and i didn't manage to understand where they came from so my conclusion was similar that they were certain transient messages which slipped through watchfish monitor.
That time i didn't have pin persistance yet so there was no way i could catch them. Hoped they would be stored now but no luck again

So if anyone else is getting these empty messages with [Action] action - try not to restart daemon but instead capture logs using devel-su / journalctl or pebble SDK / Dev Connection.

BTW these normally looking json notifications - were they normally shown as notifications or you just see them stored but they weren't popping up on pebble (hence could potentially be empty malformed pins)?

They appeared just like normal notifications, complete with the watch buzzing. Just no text...

I didn't realise rebooting it would make them go away - I was just trying to get it to bring up a new one. Not much help for debugging though, sorry...

pushed timeline7 beta. That includes UTF8 fix. Also it has TImeline Rest button - to resync timeline completely - including calendar and web pins.

I've found that when pebble resets it may lose certain pins. Web, calendar, reminders, whatever. However since they are stored locally and were acked - they are never redelivered. Also I've discovered that current timeline reset operation was a big mess, it basically didn't work. net result - timeline goes out of sync and there's no way to fix that (except of course stop daemon and wipe timeline folder).
So reset button does exactly that - wipes local storage, wipes watch pin blobdb, and requests resync from calendar and web.

I would say that battery drain has increased significantly. I currently need to charge my phone twice a day (before every 1.5 days). However top says that max cpu usage of rockpool is ~1%

can you try timeline7 - i have increased wakeup timers there, just to compare.
Also does the increased drain happen disregarding whether websync is enabled or not (when sync account logged out websync is disabled)?

To my observation drain is inconsistent, I can spend whole day losing 10% and then for half an hour it eats remaining 90%. Mostly when there's connectivity problems (eg. in the tube)
Twice a day though is really hard case, i used to charge my jolla once a week, then twice a week (as battery wears out). Now when I'm debugging app it also discharges quite fast, but still, at least one or two days is what I consider normal

Okay I have installed it and will report later. If there is no change with the new version I will disable the web sync.

Jip it's quite annoying right now. Until recently the battery lastet about 2 days. Then I had a drop to about 1.5 days and now under one day. Once a week sounds awesome but I think that is not possible with alien dalvik activated :\

I've reviewed google - too much overhead with their registration and stuff.
wit looks better although given that it's already linked to saera - see no reason to redo it natively.

The way I'm implementing transcription interaction now is following:

1. Pebble sends voice setup request
2. Rockpool receives request and attempts to create temp file where voice session will be dumped
3. If temp file opening fails - it nacks request
4. otherwise it acks request and emits dbus signal TranscriptionSessionStart(s:tempFile, s:format, s:appUuid)
5. when first audio frame arrives it emits TranscriptionAudioStart(s:tempFile)
6. when audioStop is received from pebble it flushes the file and emits TranscriptionAudioStop(s:tempFile) and fires up a timer for 4sec
7. when TranscriptionResults(aass) is called timer is rearmed to 500ms
8. till timer times out it collects additional results from other providers (if any), sorts results by confidence and after 500ms since first result it replies back with merged results
9. finally sends TranscriptionSessionClosed(s:tempFile) and cleans up the mess
10. when no results submitted over 4sec slot it replies back to pebble with RecognitionTimeout error, sends SessionClosed and cleans up the mess.

SessionStart format will be a string representation of the audio stream format in mime content-type form. Pebble now supports only speex so it will be "audio/speex; rate=16000; bitrate=12800; version=4; frame=320". appUuid will contain uuid of the application which initiated the transcription. will be empty (0-0-0-0-0) for system initiated (eg. response)

TranscriptionAudioStart - not sure if we need it, the idea is if transcription service can tail the file to speed up recognition. I doubt this is really possible so most probably will drop it.

TranscriptionResult aass structure will be a representation of native pebble transcription result structure, which is array of arrays of objects containing word and its confidence, eg. [ [ {"confidence":50, "word":"hello"}, {"confidence":50,"word":"world"} ], [ {"confidence":50, "word":"hello"}, {"confidence":40,"word":"word"} ] ]. That is - list of sentences, each sentence consisting of word:confidence pairs, word maybe printable word or punctuation mark.

At the moment going to dump raw speex bitstream to the file. Jolla has libspeex installed so technically could do stream decoding however apparently it should be performed in the platform integration, not libpebble (where it ends atm). And if I go for the platform - it would make sense to make at least one native implementation in the platform using some cloud service.

If anyone has any suggestion to improve/amend the interaction - please chime in.

Finishing voice endpoint and some clarifications revealed over the course of testing:

• Pebble accepts just one sentence in reply, so rockpool will do sorting based on avg confidence (if there are more than one sentence in the reply) and send the highest one.
• Pebble accepts recognition response only within two seconds window after audio stop. So rockpool will send response with timeout if there is no response for 1600ms after stop signal.

Some update on the current progress - which is going to land soon into next beta.

So voice endpoint as was written above is implemented. For now it will just send dictation result containing sentences "Noone dared to reply. Service timeout" as a proof of concept. However if anyone replies via dbus with proper results within allotted time slot - that result will replace the stub one.

Another feature addition is Pebble language support. Now you can change the language (and/or character set) of the Pebble watch from rockpool GUI. It uses official language packs from pebble fetching them using json API from bootstrap config provider.

Then there're several bugfixes.
Major one is daemon crash on call end - which improves daemon stability. Occasional crash on reconnect still remains though. But this one is less frequent.
Less obvious and not final yet is slight rework of timeline timers which fixes one of the high battery drains (the one I mentioned which happens in absence of internet).

Timeline power efficiency has not been completely resolved yet, which does not allow us to push it to mainline. That is - with timeline you may expect still "higher than usual" power consumption happening under certain unknown yet conditions.
Other known issues with timeline are pin re-delivery (fixing it now) and reminders not working properly (need yet to figure why). Once these are closed - new beta will be pushed,

New beta posted, in addition to above-mentioned fixes I've also stepped up software release as communicated to pebble as well as extended protocol capabilities with Weather and SMS support. As result you would see new apps on pebble (Weather and Send SMS) - they however are not yet configurable so are quite useless till configuration protocol is implemented and hooked to GUI.