Unable to start timers

[P9k]

In addition to https://github.com/MrApplejuice/BabyBuddyAndroid/isues/35 (the issue regarding logging diaper changes), it is now impossible for my partner to start any of the timers using the Google Playstore version of Babybuddy.

The "start" button of a timer can be pressed, changes appearance for a very short time to a "save" button (but does not actually record a timer) and then reverts back to a play button within maybe 0.5 seconds, without ever showing any time passing.

Interestingly, my partner can stop timers started by me on her phone and is then able to start a timer herself within a short time window (maybe within 5 min) before the program is going back to the behavior described above.

A bit background to possibly help speeding up bug fixing:

The Babybuddy backend is hosted on our Linux homeserver running using "docker compose" and is up-to-date. We have tried restarting my partner's phone (Huawai P30) and our server several times now but immediately run in this behavior.

On my phone (Xiaomi Redmi Note 10) the problem never occurred.

Some guidance or a suggested fix would be highly appreciated! :)

[MrApplejuice]

Hey P9k!

Oh man, this really sound like a serious issue! I am very sorry that you experience this error.

First of all to get this out of the way: If you are really unhappy and since you bought the app on Google Play, I can of course, offer you a refund. Please send me an email in that case to [email protected] in that case, because we need to exchange some details about your purchase then.

---

However, I would also be very happy to work this out with you. I did not experience this exact error yet, so being able to observe what is going on would be great! Of course, I do not want to collect data about your family or children, so I would suggest the following course of action:

I can invite you to the internal testing track for the app and offer you to install a special version of the app from there which will collect extra logs about the app <-> server interaction. Those logs will NOT automatically be shared with me. Instead, I would create a special menu entry in the app-menu that will reveal the logs and allow you to edit/copy them.

I would then ask you to try to start/stop a timer and the copy the logs and send them to me. Since you can edit the see what is in the log files, you can make sure that there is no information in there that you do not want to reveal to me.

If you want to go this route, please reply, because I need to set some things up. We also will need to exchange email addresses in that case so that I can add your google-account to the internal tester list. Do not post your google-account here! Send it also to [email protected] in that case.

If you can help me with collecting the logs, I am sure that I can fix the app for you. I will need a few days to set this up as well, so this might take a little bit. If you want to go through with the cooperation, I would suggest to also address #35 immediately as well then!

I think that is the best I can do for you right now, because I really have no clue why even timers would not want to start... please either send me an email or respond on this thread if you are interesting in collaborating on this.

Kind regards,
Paul K.

---

Some more details on what you wrote:

We have tried restarting my partner's phone (Huawai P30) and our server several times now but immediately run in this behavior.

I do not suspect that this will help, no. There seems to be a systematic error of some kind.

[MrApplejuice]

Maybe some more superficial question about things that could give me hints of what is going on (answer only if you are happy to reveal that data 😃 ):

• What timezone are your mobile phones using?
• Does your language use non-ASCII letters in your alphabet? Something that is not in abcdefghijklmnopqrstuvwxyz? If so, which letters/what language do you use babybuddy with?

[P9k]

Hi Paul,

Thank you so much for your detailed response and the offer to figure out together what is going wrong. :-) No need for reimbursement - we are very happy with your app as it is super useful for our tracking the needs of our little one and I would like to support your work!

I am more than happy to assist with helping figuring our what causes our issues (I am feeling that it has to do with my partner's phone in some capacity..), so I will write you an e-mail to discuss things further. 👍

[P9k]

* What timezone are your mobile phones using?

We are on Central European time (Europe/Berlin)

* Does your language use non-ASCII letters in your alphabet? Something that is not in `abcdefghijklmnopqrstuvwxyz`? If so, which letters/what language do you use babybuddy with?

We are German-speaking, so only the dreaded umlauts are somewhat special. But they are not part of our child's name and don't appear anywhere in our user data as far as I am aware.😅

[MrApplejuice]

No need for reimbursement - we are very happy with your app as it is super useful for our tracking the needs of our little one and I would like to support your work!

Thank you very much then! If I cannot fix the bug to your linking, please do not hesitate to ask for the refund anytime.

Other than that, we are in direct email contact now, and will setup the test-track that way.

Thanks for answering the quick set of questions, nothing special in there. I was just guessing what could have gone wrong. But all of that seems to be well withing the general ballpark of things I am usually testing myself...

[P9k]

Hi Paul,

Miraculously, the issue has vanished without me actually knowing what had helped.

One possibility is that the upgrade of the BabyBuddy server software from version 2.0.2 to 2.0.3 two days ago made the problem disappear.

From my perspective, the issue here can be closed. If you like, we can keep the option of sending you logs from the debugging version of the app im Hinterkopf. ;-)

[MrApplejuice]

Hey P9k,

Thank you for letting me know. I actually finished the debugging screen now and was about to draft the release on saturday but if it is resolved, then... there is nothing to do anymore I think. Great for you! Ping me if it re-appears. I can roll out the new version rather quickly now for the purpose of log-collection.

A bit unfortunate as well, because I saw issue #35 myself on a device that I do not have direct access to. I will leave this issue temporarily open for this reason.

I will go back to feature development then. Happy baby tracking and good luck to you and your family!

[MrApplejuice]

Actually a good question - is issue #35 resolved for you as well @P9k ?

[P9k]

Actually a good question - is issue #35 resolved for you as well @P9k ?

Yes, it is

[MrApplejuice]

Okay, very good then. As I said: feel free to ping me if it re-occurs, then we can debug this again, maybe. Until then: Good luck with being a parent!

---

A debug-view was added now as part of #40 . So if someone else experiences this issue, debugging options have been prepared!

[P9k]

Hi Paul,

Unfortunately, the problem is back.. 😅

[Akisaga]

Hi,

I think this has something to do with the time of the phone beeing ahead of the server time.
For some reason babybuddy does not allow events to be placed in the future. (On the web version you will get an error message)
Is it possible to get the server time when creating those events instead of using the local time of the phone?
Maybe this could fix the problem.

[MrApplejuice]

Hey Akisaga,

Thanks for commenting! And yes, indeed, server-time <-> mobile-time synchronization is a problem and I try to address that in the code, however, I am still having trouble reproducing this particular issue and am not sure if or how or why this is still happening. Here my rationale up until now:

https://github.com/MrApplejuice/BabyBuddyAndroid/blob/b82c4900074d9f528fa2d7af8d200d0d5dc85cc7/app/src/main/java/eu/pkgsoftware/babybuddywidgets/networking/BabyBuddyClient.java#L496-L511

This part of the code attempts to calculate the server-time <-> mobile time offset (see the line with serverDateOffset = ...). This then later-on is used when:

1. Rendering the timer-start time after a timer is started. The start-time that is sent by the server is converted to mobile-time for displaying the seconds correctly.
2. Sending messages that contain a time to the server like createTimer.

The code I wrote attempts to measure the time between server-time and client time using:

https://github.com/MrApplejuice/BabyBuddyAndroid/blob/b82c4900074d9f528fa2d7af8d200d0d5dc85cc7/app/src/main/java/eu/pkgsoftware/babybuddywidgets/networking/BabyBuddyClient.java#L506

Even with network delays this should always date back all messages by at least 100ms. If there is network delay it should date back messages even more (if I see it correctly). I cannot see, unless if there is an enormous network jitter, how this will lead to times not being "server compatible".

Right now, createTimer is crucial for creating a new timer for entries, so this could be the problem why start-timer does not work - the starting point for analyzing the problem. However, I can only see this failing in cases of:

1. High network latency jitter, but that would mean that a few times it works, sometimes it does not.

• This could be fixable by doing a more statistically sound implementation for adjusting the server-time off set. Taking a weighted sum of multiple server time-offsets, for example.

2. I think this is the most likely reason. The server omits or contains a malformed "Date" header or the "Date" reported by the server deviates too much from the actual server time. The date-header is quite finicky to parse in the first place. I have hand-written that code. So I suspect that this is the culprit. However, I was not yet able to confirm this. And even if I know that this is the issue, I need see how this is not working or why so that I can fix it.

In lack of any more "hard evidence" on this issue, I was thinking about trying a retry-logic with 1s intervals. However, that will not "feel good" so I am not so happy with that solution. Also: I already tried a retry-logic some time ago for the conflict resolution dialog - if you stop a timer but that timer entry then overlaps with an already present, manually entered timer entry. Also did not work.

So if you have any further ideas on this, I would be happy to hear them!