NanoClock: Yet another persistent clock

[Phil_C]

After a cold boot and a connect to USB, the log file was zero bytes and empty. A second connection to USB gave me this new log file:

[Carmelocotonto]

Yes, I can see the clock under USBMS and it is updated correctly, with 0.9.6


[QUOTE=
@Carmelocotonto: Since you mentioned KOReader, one interesting data point would be to check if you actually see the clock ticking in KOReader's own USBMS tool... (as it's basically the same piece of code).[/QUOTE]

[NiLuJe]

Originally Posted by Phil_C

After a cold boot and a connect to USB, the log file was zero bytes and empty. A second connection to USB gave me this new log file:

Yeah, the round-trip is perfectly normal.

And that looks much better, actually .

It's conceivable the software clock is highly irregular and getting its ass kicked by NTP, I'll be adding some tweaks to detect that, and making the logs clearer, thanks!

[NiLuJe]

Originally Posted by Carmelocotonto

Yes, I can see the clock under USBMS and it is updated correctly, with 0.9.6

Note that I was speaking about the USBMS tool's own status bar, not NanoClock .

But then I remembered that on a Clara, you'll also get charge ticks, and those also update the status bar, so, that wasn't a great testcase anyway ^^.

[Carmelocotonto]

In any case, I confirm that both the koreader clock and the nanoclock are updated

Originally Posted by NiLuJe

Note that I was speaking about the USBMS tool's own status bar, not NanoClock .

But then I remembered that on a Clara, you'll also get charge ticks, and those also update the status bar, so, that wasn't a great testcase anyway ^^.

[NiLuJe]

There's also a bit of a catch-22 in that if NanoClock is displayed inside the status bar's region, then an update of the status bar will *also* update NanoClock ^^.

[NiLuJe]

Okay, released v0.9.8 .

* On Mk. 6+ devices, the clock tick timer is now rearmed every time the clock suffers a discontinuous change (e.g., ntp). This should *hopefully* fix the autorefresh weirdness mentioned above.
(I'd have handled it everywhere if I could, but it depends on a feature introduced in summer 2011 (!!) in the Linux kernel, and older devices run a truly terribly ancient kernel).
* Handle some extreme corner cases where a refresh storm could lead to false negatives (i.e., missed clock updates). Shouldn't really ever happen in practice.
* Added some more logging, especially in debug mode, which should make why things happen (or not ;p) much clearer.
* Added some new configuration settings to control how exactly the {battery} & {frontlight} placeholders are expanded. In particular, this allows configuring the battery one both within and without the threshold (meaning if you like to put your battery meter between brackets or something, but got rid of the thresholds because it was ugly as sin otherwise, now you can actually get the whole thing working. See the default config for more details and an example of this).

[Phil_C]

Here is the v0.9.8 log. I went into a book and the clock did not update for about 7 minutes, until I touched the screen. If I understand the log correctly, you can see at lines 81-82 that nothing updated between 17:43 and 17:50.

[NiLuJe]

@Phil_C: Were those seven actual minutes?

Because it looks like the clock is *severely* drifting for a while... until you get out of USB, which is a point at which Nickel may do a hard resync to the hardware clock, which might shock the thing into saner behavior...

I guess I can try to fire the clock ticks from another clock source, but I'm not sure it'll get any better, and it'll be a dumb "every 60s" timer, not "on every minute change" :s.

[Phil_C]

Those were 7 actual minutes where I entered a book and just let the reader sit. Then I touched the screen and the clock updated. Clara was NOT connected to USB during this time.

I have to connect to USB, then disconnect, then connect once more to get the log for what I did before the first connect. As you said -- kind of clunky. But it's the only way I know how.

[NiLuJe]

Okay, then...

Does this version behave any better?

(I'm still mildly miffed I can't see the startup banner in your last log, which doesn't make much sense, unless something's mucking with your syslog daemon, but this is somewhat unrelated to the issue at hand ^^).

[Phil_C]

Here I installed v0.9.8-12 and did a cold reboot of the Clara. On the Home screen starting at time 20:19, the clock updated to 20:20 on schedule.

I opened a book and changed a page or two and let it sit for 5 minutes. No further updates (stayed at 20:20) until I changed the page after those 5 minutes.

Back to the Home screen at 20:25 and you can see the clock updates as it should to 20:26 and beyond.

.ini file included just for fun.

[NiLuJe]

Okay, new theory: the reader is putting the device to sleep when inactive.

This version *should* make that clear in the logs...

(In which case, it's a "good" thing. I mean, I can make the clock tick wake the device up, but that's not necessarily a great idea ^^).

EDIT: Yup, confirmed on the Forma (if I actually let it sit without Wi-Fi ;p).

[Phil_C]

This one is worse. Sometimes the clock does not update on the HOME screen, so the Kobo clock and the NanoClock show different times -- until I touch the screen.

Here the clock failed to update in a book for 3 minutes from 22:14 to 22:17.

The clock failed to update on the Home screen from about 22:18 to 22:22. But the log does not appear to show this! A display glitch maybe? It does not happen every time on the home screen.

(Separate question: Do you ever sleep?!? )

[NiLuJe]

Yeah, the fallback trickery ends up making things worse in this case (as either the timer's initial expiration is off, or not in sync w/ real wall time) ^^.

But, yeah, I confirmed my suspicion on the Forma.

And I just tried what happened if I attempted to break Nickel's careful planning by forcing a wakeup on clock ticks... and, yeah, it's as stupid as expected, and will royally screw with what it thinks is happening (i.e., just glanced at it, it tripped a full suspend on my Forma ).

Aaaanyway, many thanks for your patience and experiments, because most of the changes involved *are* sane and useful .

I'll be documenting that properly, clearing up the useless parts of the latest experiments, and doing a new release tomorrow ^^ (so: now, would be the answer to your question ^^).