16:00:47 <anadahz> #startmeeting
16:00:47 <MeetBot> Meeting started Mon Feb  6 16:00:47 2017 UTC.  The chair is anadahz. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:47 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:48 <sbs> yo!
16:00:56 <anadahz> hi
16:01:15 <slacktopus> <alangiu> hi!
16:01:50 <darkk> yo!
16:02:18 <anadahz> Agenda pad: https://pad.riseup.net/p/ooni-irc-pad
16:02:49 <hellais> hello
16:04:15 <sbs> uhm, the agenda looks like crickets
16:04:28 <anadahz> true
16:06:41 <slacktopus> <agrabeli> hello
16:09:25 <anadahz> Does anybody have something to bring up for discussion this week?
16:09:49 * darkk hacks
16:12:34 <darkk> also, ooniprobe-android scheduler code seems to be unstable -- it can't be left unattended in lepidopter-style yet. But I'm unsure if I can reproduce the bug reliably (have not tried that yet)
16:14:58 <sbs> specifically, what happens? it misses tasks? executes them more than once?
16:15:28 <sbs> my experience with it, so far, is that tasks are executed once but execution is off by several minutes
16:16:02 <sbs> like: I scheduled a test for 16:28, it executed at 16:33; scheduled another at 16:53 and run at 16:58
16:16:08 <darkk> sbs: it just stops executing scheduled daily measurement, but the scheduler is enabled in settings
16:17:14 <sbs> darkk: ack... so we have two different symptoms: in your case it skips measurements (and you did change the timezone) and in my case there is a small offset
16:17:30 <sbs> I am wonder whether we can generalize this by assuming there is some variable offset
16:18:22 <sbs> how can I try to confuse the scheduler with time zones? set the notification time, change time zone such that it goes past the alarm, go back with time zone? or is the procedure different?
16:18:41 <darkk> sbs: IMHO, small offset is ok and may be cause by powersaving settings
16:19:23 <sbs> darkk: uhm, however, the procedure here was like: boot the device, delete the old app, install the new app via usb, set the alarm five minutes in the future, leave the device unattended
16:19:54 <darkk> sbs: my case actually have two possible causes: 1. timezones 2. phone skipped one measurement due to being off and could not re-arm timer. Scratch that, the third one: 3. phone reboot (timer was not re-armed after reboot)
16:20:38 <nuke> hi all
16:20:56 <darkk> I've not read the code/logs, so those are just uneducated guesses :)
16:21:13 <nuke> darkk I still haven't looked into that issue, but I'm pretty sure looking at the code I will understand what is the problem
16:21:15 <sbs> darkk: ah, I've just noticed a pattern in my behavior: I set twice the alarm five minutes in the future from "now" and it run five minutes _after_ the expected expire time... so now it's set to 17:35 (fifteen minutes from now).... let's see where it fires at 17:50 :-P
16:21:38 <sbs> s/where/whether/g
16:21:42 <hellais> I think the inaccurate timing is due to the use of setInexactRepeating: https://developer.android.com/reference/android/app/AlarmManager.html#setInexactRepeating(int, long, long, android.app.PendingIntent)
16:24:59 <nuke> thanks for the link
16:25:10 <nuke> anyone noticed this issue on the ios app?
16:25:51 <darkk> sbs: try rebooting the phone before the bell rings 17:35 to be sure that the alarm is re-armed
16:26:31 <sbs> nuke: no, so far no, I've been testing specifically for this
16:26:39 <sbs> darkk: okay, rebooting it right now
16:36:39 <hellais> do we have more to discuss during this meeting?
16:37:06 <anadahz> If there is nothing else to discuss then we can end this meeting. :)
16:37:21 <hellais> sounds good
16:38:28 <anadahz> thanks everyone for attending!
16:38:34 <anadahz> #endmeeting