View Single Post
Old 02-15-2013, 02:18 PM   #8
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
Quote:
Originally Posted by DuckieTigger View Post
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:

Code:
****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 .
knc1 is offline   Reply With Quote