Roku Developer Program

[joetesta]

Hello,

The app I'm working on has recently experienced some issues where a Roku device has an incorrect time and it causes big problems in the time-based app.
We've seen Rokus with time far in the past and also Rokus with time a few hours in the future. In either case, the app won't work correctly since it looks for content "on now" and doesn't find the right data.
To address this I'm considering two possibilities:

1) Detect that the Roku device time is off by some minimum (say 10 minutes) and instead of launching the app, throw a warning on screen to tell the user their device time is off and they should try rebooting their Roku,
or
2) Have the app calculate the difference between the device time and the actual time as given by our APIs and use that difference as a global time offset so that the app can run normally.

In trying to test these cases, I've been having difficulty recreating the problem. This leads me to wonder if the time server issue was corrected in firmware 7.1 (by "time server issue," I mean device defaulting to the software build time in cases when the time server isn't reached). http://forums.roku.com/viewtopic.php?f=34&t=92391#p519096

Questions:
1) Was the time server issue addressed in fw 7.1?
2) Is there a way to force the device time to be incorrect so that I can test the potential resolutions?

tyvmia,
Joe

[joetesta]

Well my earlier post reminded me I could recreate the situation by rebooting the roku while hooked to the proxy (mac running charles).
Now I'm seeing the time off by some 5 million seconds and my 2nd solution looks like it's working (storing the global offset to use with all time-based functions).

So I believe I've resolved my own question but still curious for any input about these issues.
thanks again,
Joe

[EnTerr]

Assuming there is no battery-backed RTC on Rokus, there is no silver bullet to ensure the device time is near correct. Why don't you do all your times server-side? I.e. let the server decided what's happening "now" or relatively from request time.

PS. actually, just thought of something that can be done to avoid device time jumping far in the past when time server inaccessible since reboot. Set device time based on the last entry in the persistent log (or "modify" timestamp of said file) instead of build timestamp. Doing this will ensure time does not reverse back but monotonically increases (baring time server override). Not bad, RokuMarkn?

[joetesta]

"EnTerr" wrote:
Assuming there is no battery-backed RTC on Rokus, there is no silver bullet to ensure the device time is near correct. Why don't you do all your times server-side? I.e. let the server decided what's happening "now" or relatively from request time.

yep for sure that would work - however in this project I have no control or access over the server side - the roku app sends requests with a timestamp for the data it wants, and that timestamp comes from the device time. By calculating and using a global offset within the app, I have this working pretty well now.

"EnTerr" wrote:
PS. actually, just thought of something that can be done to avoid device time jumping far in the past when time server inaccessible since reboot. Set device time based on the last entry in the persistent log (or "modify" timestamp of said file) instead of build timestamp. Doing this will ensure time does not reverse back but monotonically increases (baring time server override). Not bad, RokuMarkn?

yep I thought of that back in January when this cropped up - for sure the way Roku firmware handles it should be improved, imho.

[RokuMarkn]

"EnTerr" wrote:

PS. actually, just thought of something that can be done to avoid device time jumping far in the past when time server inaccessible since reboot. Set device time based on the last entry in the persistent log (or "modify" timestamp of said file) instead of build timestamp. Doing this will ensure time does not reverse back but monotonically increases (baring time server override). Not bad, RokuMarkn?

Hm, what "persistent log" are you referring to? There are some files in nvram, but I'm not sure there's one that's updated regularly.

--Mark

[EnTerr]

"RokuMarkn" wrote:
Hm, what "persistent log" are you referring to? There are some files in nvram, but I'm not sure there's one that's updated regularly.

Well, since i cannot see the underlying file system/processes, i am bound talking out of my ... mule. 😛 </truth-disclosure>
But there ought to be a file in nvram whose timestamp/content can be used as watermark that "always" (loosely speaking) goes up with reboots? So even if the box keeps rebooting with no time server, the local time will keep limping^ forward.

It's imperfect yet incremental improvement over always using the build time, which in turn is an improvement over always staring from the Unix epoch (1970). Now does that survive cost/benefit analysis, i do not know.

(^) march to the beat of a different drum

[joetesta]

argh, now i'm testing and running into an issue with 'GetTimeZoneOffset()' when the system time is before daylight savings begins; the offset is off by an hour.

Note: the time zone offset is returned for the current date/time, regardless of the object's date/time value.

https://sdkdocs.roku.com/display/sdkdoc/ifDateTime#ifDateTime-ToLocalTime()asVoid
I'm going to try to use 'ToLocalTime()' and subtract from calculated GMT to get the actual offset. UPDATE: yep, this works!