[SleepLog] screen refresh issues on banglejs 2

[m0n5t3r]

Affected hardware version

Bangle 2

Your firmware version

2v18

The bug

Everything updated, the sleep log app mangles the output when switching between days (left / right swipe), see image

expected behaviour: display texts properly, not have junk displayed on the left of the screen, or the "calculating data, please wait" text visible at all times

Installed apps

simple clock simple pedometer charging status thermometer launcher message icons weather heart rate monitor alarms widget daylight saving scheduler health tracking alarms & timers astrocalc tea timer bluetooth widget compass notifications (default) bootloader batery level widget (vertical) messages sleep log settings my location message ui android integration

[ticalc-travis]

I just had this happen to me (Bangle 2, 2v19) after having used Sleep Log for a few months. It occurred immediately after changing the time zone setting (actually, installing Daylight Saving to do it for me). Was fine the previous day, then the next day after the time change, the UI is unreadable just as in the screenshot, apparently permanently. Possible clue?

[bobrippling]

I've had a skim through the code and noticed a width being used in place of a height, I'm not sure it impacts the exact issue here but I've deployed it if you wouldn't mind giving it a go?

@storm64 how does this look to you?

Out of interest, does the issue appear consistently now, or just temporarily after changing the timezone?

[ticalc-travis]

It seems consistent: even after changing the time zone back to its original setting the problem persists. It also persists when viewing past logs, including dates from previous log files before the currently-written one. I'll watch and see if the situation changes once the current log where the time change happened gets rotated out in a few days.

It doesn't appear that #3085 patch improves anything, unfortunately.

Edit: I also tried checking the console when running Sleep Log in the broken state but didn't see any errors or messages reported.

[bobrippling]

Thanks for the update and for trying out the patch even so - in that case the issue will be in the drawing code most likely, just an overlap of two draws. But yes, nice idea, let's confirm if it happens when the rotate-out occurs too

[ticalc-travis]

I haven't had time to investigate further, but a quick confirmation that even after a log rotation the symptoms are still present so far. The data still seems intact and reasonable if I view it from the app launcher, but it's still a mystery why the app UI remains confused so persistently.

[bobrippling]

No worries, thanks for confirming - @storm64 I don't suppose you saw anything like this during development of the app?

[storm64]

I just got my BJ2 up to date with all apps and haven't experienced this bug for now.

Tried to change the timezone manually to trigger the drawing issues, but the app draws as it should.

I might have an idea though: As you change the timezone and a sleeping state change is logged, its timestamp could be before the previous logged timestamp. As I remember the logged timestamps should be correct to UTC, but maybe there is something wrong on this part.

I'll try to have a look into this tomorrow.

[bobrippling]

Ah interesting, like if there's a shift back in time perhaps?

[ticalc-travis]

In my case, the local time did shift back an hour upon DST changes. Does the app use UTC internally? I wonder if it could cause problems if by some chance the internal system date/time got changed in an unexpected (i.e., non-monotonic) manner by some means and an incorrect stamp got appended in the log. It seems that would be hairy indeed to deal with.

[storm64]

The internal timestamps are all based on UTC as a timestamp is calculated from ´Date.now()´.

But I don't prevent non-monotonic system time changes as @ticalc-travis predicted. For now I'm testing with my second BJ2 what might happen on a back shift in time.

[storm64]

Even though there might be some strange behaviors on a shift back in time the mentioned bug shouldn't be one of it.

I thought, that it looks like the width variable gets reset to 0. The width is set on app start by ´var width = g.getWidth() - 1;´. Just tested it by executing ´width=0´ from the Web IDE while inside the app and the screen output looks like described.

[storm64]

I just pushed a quick try to fix the bug by changing the var name to ´myWidth´. Please check out version 0.16 on my temporary app loader: https://storm64.github.io/BangleApps/?q=sleeplog

[bobrippling]

Interesting - I wonder what else might be writing to width

If you want to check, run this after sleeplog's loaded and you might see an error backtrace when something tries to set width:

_width = g.getWidth() - 1;

Object.defineProperty(global, "width", { get: () => _width, set: () => {throw new Error("can't set width")} })

[storm64]

Thanks @bobrippling, nice way to troubleshoot.

Just changed the code again to be a bit more clean: I will recall ´g.getWidth()´ (or getHeight) on each occurrence of width, as it should'n change the runtime noticeable and might even be faster after minification.

[ticalc-travis]

I just pushed a quick try to fix the bug by changing the var name to ´myWidth´. Please check out version 0.16 on my temporary app loader: https://storm64.github.io/BangleApps/?q=sleeplog

This update does appear to restore the graph display back to normal for me. Thanks. :+1:

[m0n5t3r]

funnily enough, after I did a "compact storage" a few days ago in an attempt to get rid of an "out of memory" error when attempting to display messages, sleeplog refreshes correctly and it even has colored graphs now o.O

wondering if it's not some sort of corruption that ends up messing with whatever runs eventually, I have no idea what espruino does behind the scenes

edit: before this I think I updated the app at least once, and the problem persisted - the workaround above should make it more resilient, but I still find it strange that it happened

[bobrippling]

Interesting - let's give it a month or so and see if the bug crops up, if not, I reckon we can close this as a hardware/storage caused issue

[ticalc-travis]

I'm a bit confused as to why it would have happened myself. But on the subject of corruption, I have noticed something a bit weird with the sleeplog StorageFile from time to time that doesn't quite make sense to me. This could be a totally unrelated issue, though. Essentially, every so often (say, once every couple of weeks or so) I'll notice a brief bit of missing data in the sleeplog graph. If I view the log right after this happens, I'll find something similar to the following:

2837016,4,2
2837017,0,02837023,2,0
2837024,3,0
2837027,2,0
…

Notice the second line, which suspiciously looks like it should be two separate lines, “2837017,0,0” and “2837023,2,0”, but with the line break missing. This seems to confuse the parser. I can't determine what triggers this behavior, but oddly whenever it happens it usually seems to occur somewhere around 7 or 8 AM local time (which corresponds to roughly 12:00 to 13:00 UTC). It doesn't appear that the watch is rebooting or doing anything strange around that time; I have had an app running at the time when this glitch has occurred, and that app had continued functioning undisturbed.

I once looked through the sleeplog code but couldn't seem to find any particular code path that some bug might trigger to cause this to happen. But the code involved seems rather complex, so I could have overlooked a possibility. Or else maybe there's some sort of weird system or hardware bug going on in my case, but so far it seems only sleeplog has been affected, and I've seen this specific type of incident occur on several occasions now.

[bobrippling]

Nice spot - that might impact the drawing. On a look through, this leading comma looks a little odd, but wouldn't cause the joined lines you're seeing:

https://github.com/espruino/BangleApps/blob/2b8399bb9bd076cae54d675baebf7f89b1eeb8d2/apps/sleeplog/boot.js#L130-L134

Whereas here I notice we're using writeJSON to the log file, whereas it should probably be write - @storm64 do these seem accurate changes to you?

https://github.com/espruino/BangleApps/blob/2b8399bb9bd076cae54d675baebf7f89b1eeb8d2/apps/sleeplog/lib.js#L171-L173