Using OverDrive the Kobo Way!

[davidfor]

Originally Posted by jowit

You are a genius! It worked. I signed out of Overdrive and was able to change the date. Lucky for me, I had previously side-loaded my library book using ADE, because Overdrive is not yet supported for the KA1 for my library. Yay!
So, it seems that the option for changing the date gets disabled once you are signed into Overdrive.

I'm always happy when my guesses are proved to be right

Originally Posted by DNSB

On my KA1, the date and time options are still there but the only one that responds to a touch is the Time Zone. It doesn't matter if I have WiFi on or off. I'm logged into Overdrive.

On my H2O, if I disable WiFi, I can change the time/date and the new setting works until I enable WiFi at which point the time sync sets the current date/time.

On my Glo HD I can change the time with WiFi enabled and connected. The sync didn't fix the time the first time I tried, but I set it to 11 hours in the future. When I changed it by a couple of minutes, it did fix the time. It's probably using ntp and following its rules.

[DNSB]

Originally Posted by davidfor

On my Glo HD I can change the time with WiFi enabled and connected. The sync didn't fix the time the first time I tried, but I set it to 11 hours in the future. When I changed it by a couple of minutes, it did fix the time. It's probably using ntp and following its rules.

I only tried 15 minutes (900 seconds) so you're likely right about the ntp settings. I'm wondering if ntpd will exit if the difference is over 1000 seconds and need a restart to start again. I used to see that with a server where an application tried for 100% CPU and blocked a lot of background processes from running. Depending on what the DBA's were doing, the process would be kicked on on Friday around 9PM and run through the weekend. By Monday AM, the clock could be off by ~ one hour and would not automatically correct. When we investigated, we found a panic message from the ntpd logged. The "solution" was a cron job that ran the ntpd with a -g option on Monday at 6AM. Decimating the DBAs was discussed but never implemented.

[davidfor]

Originally Posted by DNSB

I only tried 15 minutes (900 seconds) so you're likely right about the ntp settings. I'm wondering if ntpd will exit if the difference is over 1000 seconds and need a restart to start again. I used to see that with a server where an application tried for 100% CPU and blocked a lot of background processes from running. Depending on what the DBA's were doing, the process would be kicked on on Friday around 9PM and run through the weekend. By Monday AM, the clock could be off by ~ one hour and would not automatically correct. When we investigated, we found a panic message from the ntpd logged. The "solution" was a cron job that ran the ntpd with a -g option on Monday at 6AM. Decimating the DBAs was discussed but never implemented.

It looks like they run ntpd with "-q" whenever the DHCP lease is acquired or changed somehow. And that means it shouldn't change the clock if it is more than 1000 seconds out.

Doing it this way also explains one of the things I saw. One of my tests didn't adjust the clock, but I changed it while the WiFi was active and it would have had a lease. When I turned WiFi off and on, the time was adjusted.

Anyway, a lot more than we need to know. I think the important things are:

- Connecting to WiFi will fix the time if it is less than 1000 seconds out.
- Using OverDrive requires an accurate clock and doesn't let you manually change it.