clock_info - support

Weird, I haven't got that bug recently, but I did get something similar earlier which was fixed when issue #2168 was closed.

When it hangs, do you get any error messages if connected to the Web IDE?

You don't happen to have some custom code for E.showScroller installed with outdated code somehow?

Is everything up to date with the app loader? (Main one or development one in that case?)

I don't think it should help, but you could try installing Swipe menus. If it helps it's maybe something with E.showscroller that's still using old code.

EDIT: Also, did you try uninstalling and then installing Slope Clock++ again. If this only happens in it's settings menu maybe the slopeclockpp.settings.js file has been corrupted somewhere along the way?

No custom code for E.showScroller.
I did a factoryReset and reinstalled the apps from scratch yesterday.
I have tried uninstalling SlopeClock++ and reinstalling but to no avail.
Very easy to reproduce, just scroll up and down 2-3 times.
Nothing on the IDE console.
I can also reproduce by scrolling up and down in the Utils Menu.
Problem stops when SwipeMens is installed and comes back when uninstalled.

I tried scrolling up and down on slope clock ++ settings but I don't get the bug.

If you want to, you can upload a backup of your watch here so I could restore it to my watch and see if I get the error as well, and if I could find a solution.

I have logged this hang as Issue 2382
I have narrowed down a minimum config to reproduce the issue. It is not related to Clock_Info's Or SlopeClockpp, I can reproduce with the Utils menu in settings.

I have uploaded a backup. It would be good if someone else can see this.
I have another Bangle 2 so may set that up later and retest. Just in case my hardware is starting to fail.

1 Attachment

• issue_2382_banglejs_backup.zip

I commented on issue 2382. Restored your backup but couldn't reproduce the bug.

I couldn't reproduce the error with clkinfos on my setup, however I found that the code printing that warning isn't exactly helping out with the problem..
Could you trigger the exception while adding something like

console.log(e);

in the same catch box where that is printed (should be clock_info:133).
After that, the result might tell something more meaningful.
(For simplicity I can try to set up a branch with that modification on my fork, stay tuned)

EDIT
Here you go, by uninstalling and reinstalling the offending clock (slopeclockpp) with my app loader's fork (https://glemco.github.io/BangleApps/) you should be able to use this modified version of the clock_info module. You can check the only new commit in my master branch is adding that line.

I have reproduced issue 2382 on a second Bangle 2 now.

The SlopeClockpp with Weather Clock_info is working fine without issue on my 2nd Bangle 2.
I will try adding in the other Clock Info's.
I am using your SlopeClockpp with Weather 0.22
Could this be something to do with pretokenisation ?
I have re-installed all my apps without pretokenisation.
All clock_info's working now, no pauses and errors on the IDE.

Issue 2382 still reproducable though.

Do you mean the problem is there just on 1 bangle out of 2?
It could be anything, different versions of the clkinfo module (which gets pulled on install), some outdated file/app roaming around for whatever reason, or anything else.
A better error log could help narrow it down.
Anyway I have pretokenised all of my apps and have no errors, so reinstalling might have fixed.

No I have two Bangle 2's and both will reproduce issue 2382 (the hang issue in settings, not the clock_info issue that now appears to have gone since switching off pretokenisation).

When reproducing bugs I take great care to make sure I have the same versions of apps and configuration. I usually do a factory reset and fully refresh favourites. I used to be a software tester many years ago.

I have done a video of the Settings/Hang for issue 2382.
https://www.dropbox.com/s/i4sjm9ckcyzym2v/VID_20221211_161039.mp4?dl=0

In terms of Clock_Info's I can now reliably use SlopeClock++ with Weather 0.22.
I have also created my own Simplest++ and Lato clocks that use clock_info's.
So I think I am pretty sorted on Clock_info's now.
Issue 2382 really belongs to a different thread.

Well, didn't mean to criticize your method (very neat, by the way). Just the clkinfo (and modules in general) are quite hard to track as they aren't versioned, so I first thought it could be that.
If it's about pretokenisation, I should see it soon, perhaps it gets triggered with some state of the weather file, which I didn't get yet. Let's see.

I appreciate your support and interest. Annoying that the problem has gone away and I'm not 100% certain why. Its a puzzle. It might be that I upgraded to weather 0.22.

I'm going to see if I can write a firmware ID clock_info now :)

Here's my Firmware ClockInfo.

1 Attachment

Just a quick update 2382 has been fixed in 2.16.33 firmware.

For clock_info's I am wondering what a minimal version of the show and hide functions should be ? Are they needed for clkinfofw. The firmware is not going to change and if it did there would have been a reboot. So could I just use:

       show : function() {},
       hide : function() {}

Instead of:

        show : function() {
          this.interval = setTimeout(()=>{
            this.emit("redraw");
            this.interval = setInterval(()=>{
              this.emit("redraw");
            }, 86400000);
          }, 86400000 - (Date.now() % 86400000));
        },
       hide : function() {
          clearInterval(this.interval);
          this.interval = undefined;
        }

In the reference Implementations I have always seen something like this.emit("redraw"); as only content of the show.
You are right as probably yours wouldn't really change, but emitting a redraw won't hurt (say one day you want to show something else, it shouldn't be called that often anyway).

Are they needed for clkinfofw.

As you say, the intervals are not needed, but I think this.emit("redraw"); is a good idea, since I don't believe we're always redrawing right after calling .show (just in case clockinfos can't get the data immediately)

@glemco that's an interesting one though - maybe there are some clockinfos that don't do that

By the way, I'm not quite sure I fully understand the use of show (as it is right now).
Clocks are supposed to call show, most of the times emitting a redraw, which eventually clocks are handling (on) while drawing. Isn't this equivalent to just calling a redraw on the first place (assuming no one else emits another redraw, which is the case for some clkinfos, like calendar date and battery).

If I understood correctly, the simple this.emit("redraw"); lets the clock decide when to update (in a convoluted but standard way), while other ways can force redrawing on some events or timers. Am I missing something?

The problem is, some clockinfos (eg the 'height' one) can't get the data they need to draw immediately.

So the idea was that you'd call show, and that turns on the barometer, takes a reading, and they redraws when it has one.

We need show/hide because we don't want to turn on gps/hrm/barometer/etc all the time - we just want them when the info is showing.

We also don't want to redraw the clock infos every minute/second - we want them to be able to tell us when they changed and want to redraw.

The show : function() {this.emit("redraw");} case I think is probably not right - we should probably draw all clockinfos immediately and then the clockinfo calls emit if it didn't have the right data for the first draw call/

I've just done a bunch of fixing up now...

@HughB @glemco I was wrong about the this.emit("redraw") that is called directly from show - the code that calls the clock_info should do this, and I think we should leave it out

I've tried to pull it out of all the code I can find so far

@Gordon -done a pull and can see the changes done to clkinfofw. Is it possible the 0.01 version of clkinfofw would cause a memory leak ?

So now the right way to handle the show for items that are always ready is to do nothing at all?
Are we both drawing manually (also the non-ready ones) and redrawing once data is ready/changing?
I see that the function menuShowItem is indeed triggering a redraw after calling the show, isn't it the same old story then? (Well I assume the idea is to keep it more under control)

So now the right way to handle the show for items that are always ready is to do nothing at all?

Yes.

Are we both drawing manually (also the non-ready ones) and redrawing once data is ready/changing?

Yes - things like pressure just draw -- first, and then update a bit later. I think that gives a nicer user experience

I see that the function menuShowItem is indeed triggering a redraw after calling the show, isn't it the same old story then?

I don't really understand... Items that are ready instantly should only draw once

Items that aren't will draw twice, but at least if you're scrolling through menus then they should update quickly.

Thanks, I guess I'm starting to grasp it better!
I think at this point a couple of other clkinfo would need an update then:

• the agenda should drop passed events as they are over
  
• the weather should trigger an update once the old data is expired and when up to date data is available
  
• I think the alarms are fine, since once one fires the screen is changing and going back to the clock would refresh anyway (does it always happen?)
  
  

Does it make sense?