Tools KUAL DateTime Button

[knc1]

Set DateTime from Server

All Kindle models have some means to set the system date-time, either manually, automatically, or both.
If you are "Blocking Big Brother", you will not be able to reach the Amazon time servers.

This button, when added will appear on the KUAL 'Helper' menu list.
It will set both the system time (in Linux kernel) and command Linux to set the hardware clock from the user's choice of public time servers.
Will work on any Kindle with network access by Wifi, USB cable, or non-Amazon 3G.
(Untested on the K2 - but one can hope it works there also.)

Will work while the "Block Big Brother" (BBB) firewall is active.

The button has a simple configuration file, accessible in USB storage (extensions/helper2/ntpdate.conf) where the user can set from one to four public time servers or time server networks.
As shipped, one US time server and three time server networks are configured:

NTPD_SERVER='nist.time.nosc.us'
NTPD_ALT1='0.uk.pool.ntp.org'
NTPD_ALT2='0.europe.pool.ntp.org'
NTPD_ALT3='pool.ntp.org'

Information on regional and pool server zones can be found here:
http://www.pool.ntp.org/zone/@

Information on the US time server network can be found here:
http://tf.nist.gov/tf-cgi/servers.cgi

Information on the UK time servers can be found here:
http://www.timetools.co.uk/ntp-serve...-server-uk.htm

The button will produce a "book-report" (actually, a text document) if it encounters any errors.
As shipped, the button is configured to also produce the "book-report" when successfully setting the date-time.
The configuration file has an option to turn off the "Success book-report", the default is to produce the success report.

The success report is enabled by setting the configuration file to:
NTPD_REPORT='true'

The success report can be disabled by setting the configuration file to:
NTPD_REPORT=''

BIG NOTE: When dragging or copying an update to this button into the extensions directory, it will over-write your modified ntpdate.config file.
Not tragic, unless you had to change the time server list.

The configuration file is actually a fragment of a script, it **must** use Linux line-endings.

Installation:

• Unarchive the release package (if using the 'zip' package, keep the directory structure) ;
• The top level directory of the button file structure is: 'helper2' ;
• Copy this top level directory, its sub-directories and files as an entry in the: 'extensions' directory ;
• The 'extensions' directory can be seen over USB storage, right next to the 'documents' directory ;
• You are done.

Finding the 'book-report'
Since the book-report is actually a text file, your kindle will consider it a 'doc' rather than a 'book'.
If you have a display filter on your Kindle ('My Items' dropdown thing), then set it to either 'all items' or 'docs' to see the DateTime book-report.

Sources:
http://hg.minimodding.com/repos/sys/kBBB.hg/summary

Changes:
1.0.1 - try to compensate for slow DNS resolvers and fix the problems with Kindles not showing the most recent report document.

[mc2739]

@knc1

Your helper2-1.0.0.zip seems to be missing the bin/ntpdate.sh file (it is in helper2-1.0.0.tar.gz though)

[knc1]

Originally Posted by mc2739

@knc1

Your helper2-1.0.0.zip seems to be missing the bin/ntpdate.sh file (it is in helper2-1.0.0.tar.gz though)

Thanks, FIXED

[knc1]

I have noticed that with my Kpw asleep for 12 hours, the time base will have drifted nearly 0.1 of a second (reported as: 'offset: ' in the book-report when re-setting).

So a "tap a day" should be enough to keep the file time-date stamps consistent.
At least if my Kpw is representative of sleeping Kindles.

[twobob]

Originally Posted by knc1

I have noticed that with my Kpw asleep for 12 hours, the time base will have drifted nearly 0.1 of a second (reported as: 'offset: ' in the book-report when re-setting).

So a "tap a day" should be enough to keep the file time-date stamps consistent.
At least if my Kpw is representative of sleeping Kindles.

Good to know.

The DX often wanders by many hours sporadically and then plays catch up on 3g "connect", this is of course a known, other, phenomenon, but I was short of things to talk about and it was not entirely uninteresting and vaguely related

Thanks for the metric on slippage. perhaps I should leave one in a coma for a week or so and see what the slip is like. But, as you say: With the new shiny "Make it So" button "Who cares?"

[knc1]

On your DX - -

Log in to 3G so that they system time is correctly set -
Steal the one-liner 'hardware clock set from system time' command out of the DateTime script, run that on the DX.

I suspect that the sporadic jumps in time is caused by the kernel re-reading an improperly set hardware clock.

[DuckieTigger]

In your ntpdate.sh, after moving the logfile to /mnt/us/documents/ntpdate.txt, why not opening that file so you can look at it? Like this (in red) in ntpdate.sh:

****snipsnip****

if [ x$RPT == 'xtrue' ]
then
  mv $LOG /mnt/us/documents/ntpdate.txt
  dbus-send --system /default com.lab126.powerd.resuming int32:1
  lipc-set-prop com.lab126.appmgrd start \
    app://com.lab126.booklet.reader/mnt/us/documents/ntpdate.txt
else
  rm $LOG
fi

exit 0

Just tested it and it works - it will open up the logfile to look at it. Another idea to improve might be to have the logfile NOT in /mnt/us/documents, so that the indexer does not have to worry about it. Maybe have it in /mnt/us/opt/log/ntpdate.txt and add a KUAL button to:

lipc-set-prop com.lab126.appmgrd start app://com.lab126.booklet.reader/mnt/us/opt/log/ntpdate.txt

(not sure if that works in the menu.json directly, or if you have to wrap it around another shell script)

This works fine by editing menu.json to:

{
    "items": [
        {
        "name": "Helper",
        "priority": 0,
        "items": [
            {"name": "Set DateTime from Server", "priority": 1, "action": "bin/ntpdate.sh"},
            {"name": "Show DateTime log", "priority":1, "action": "lipc-set-prop com.lab126.appmgrd start app://com.lab126.booklet.reader/mnt/us/documents/ntpdate.txt"}
        ]
        }
    ]
}

(might need to consider to move it to different folder then, better a subfolder, as the reader creates ntpdate.sdr subfolder.)

[knc1]

Originally Posted by DuckieTigger

In your ntpdate.sh, after moving the logfile to /mnt/us/documents/ntpdate.txt, why not opening that file so you can look at it? Like this (in red) in ntpdate.sh:

****snipsnip****

if [ x$RPT == 'xtrue' ]
then
  mv $LOG /mnt/us/documents/ntpdate.txt
  dbus-send --system /default com.lab126.powerd.resuming int32:1
  lipc-set-prop com.lab126.appmgrd start \
    app://com.lab126.booklet.reader/mnt/us/documents/ntpdate.txt
else
  rm $LOG
fi

exit 0

Just tested it and it works - it will open up the logfile to look at it. Another idea to improve might be to have the logfile NOT in /mnt/us/documents, so that the indexer does not have to worry about it. Maybe have it in /mnt/us/opt/log/ntpdate.txt and add a KUAL button to:

lipc-set-prop com.lab126.appmgrd start app://com.lab126.booklet.reader/mnt/us/opt/log/ntpdate.txt

(not sure if that works in the menu.json directly, or if you have to wrap it around another shell script)

It is a though to keep in mind.

But I was assuming that people would do one of two things:
1) Read it and keep it (somewhere) for a "most recently set" record.

2) Just delete it.

And now with four time server addresses (ntpdate uses all that it can reach of the four, and then computes the 'best' of those) - -
And the last one of those the 'global' pool - -
The button should succeed more often that not. (a lot more often)
Anywhere in the world.

Once the end-user has acquired some confidence that the button works in their location - -
Then they can decide if they want the success record or not.

If they disable the success record, then the only time a report will be made is on a failure of some sort.

So far - we have had only a couple of dozen downloads - and only one report on if the button works (from twobob).

But still that is a thought to keep in mind.
Just need a bit bigger sample of user opinions now.

PS: Yes, any single line (including multiple statements) shell command will work in the "action" : field of menu.json .

[DuckieTigger]

Originally Posted by knc1

It is a though to keep in mind.

But I was assuming that people would do one of two things:
1) Read it and keep it (somewhere) for a "most recently set" record.

2) Just delete it.

And now with four time server addresses (ntpdate uses all that it can reach of the four, and then computes the 'best' of those) - -
And the last one of those the 'global' pool - -
The button should succeed more often that not. (a lot more often)
Anywhere in the world.

Once the end-user has acquired some confidence that the button works in their location - -
Then they can decide if they want the success record or not.

If they disable the success record, then the only time a report will be made is on a failure of some sort.

So far - we have had only a couple of dozen downloads - and only one report on if the button works (from twobob).

But still that is a thought to keep in mind.
Just need a bit bigger sample of user opinions now.

PS: Yes, any single line (including multiple statements) shell command will work in the "action" : field of menu.json .

That is a fair. When I tried the button it always failed. I wonder if it has to do with me not having wifi on. (I knew that). Maybe only display the log automatically IF it fails, otherwise keep the record for reference and viewable with the button solution in KUAL? That would be great.

And also thank you for the idea - did not know how to start the reader with a script (searched that just to answer) - great way to e.g. create any output in /tmp, display it, and let the Kindle worry about when to delete the /tmp folder to make room. (I do hope it does that )

[knc1]

Ah, I never leave it behind in /var/tmp -
It is either moved or removed.

A view last setting helper button?
Should be a one-liner in the menu.json file.

But it would mean moving it somewhere other than documents.

And since I don't use any of the "Collection Management" stuff - I don't know how this will react if someone has put the success report into a "Collection" of reports.

What I really need at this point is more than 2 dozen silent users.

[DuckieTigger]

Originally Posted by knc1

Ah, I never leave it behind in /var/tmp -
It is either moved or removed.

A view last setting helper button?
Should be a one-liner in the menu.json file.

But it would mean moving it somewhere other than documents.

And since I don't use any of the "Collection Management" stuff - I don't know how this will react if someone has put the success report into a "Collection" of reports.

What I really need at this point is more than 2 dozen silent users.

I feel you on the silent users. No complaints is good news, I guess.

[knc1]

Originally Posted by DuckieTigger

I feel you on the silent users. No complaints is good news, I guess.

I just tried (on Kpw-5.3.3) to put the 'ntpdate' report into a collection named: Reports.

Then updated the date-time.

Then looked at the ntpdate report (which remained in the collection: "Reports" after its update).

A strange thing happened -
The first time I looked at it, it still showed the old information.
But on the second and subsequent looks, it showed the new information.

The system must be caching the document somewhere and just taking a little while (seconds) to clear the cache of outdated material.

I haven't tried the same with ixtab's Collection Manager.
Will leave that to someone with time on their hands.

[twobob]

Yeah. I suspect you are 100% correct. but where. who knows

[knc1]

Originally Posted by twobob

Yeah. I suspect you are 100% correct. but where. who knows

In the annotations cache.

Version 1.0.1 released in top post of this thread.

Fixes for:
1) Slow DNS resolvers
2) Kindle indexer not showing you the most recent ntpdate action report.