Roku Developer Program

[Komag]

How long can a roTimespan run/count without marking it?

I assume there is some point where there would be a memory problem, counting millions/billions/whatever of milliseconds. Is that measured in hours, days, weeks, years? If someone plays my game, leaves the game on all night and all day and all night for a week, will the roTimespan cause a memory error and crash the game?

There are 86.4 million milliseconds in a day 😄

[TheEndless]

Probably safest to assume somewhere in the 2.1 billion range.. the size of a 32-bit signed integer. It may be stored as unsigned, which would double that. So I'd guess somewhere between 24 and 48 days...

[Komag]

If that's the case then its plenty of time, no need to try to work around it 🙂

(I tested overnight, counted and printed up to 24,918,363 milliseconds before I turned it off, no problems)

[RokuMarkn]

It uses a 64 bit unsigned integer to hold milliseconds, so it will overflow after about 584 million years.

--Mark

[Komag]

:shock: :shock: :shock:

[TheEndless]

"RokuMarkn" wrote:
It uses a 64 bit unsigned integer to hold milliseconds, so it will overflow after about 584 million years.

--Mark

Curious.. how is it returned to BrightScript which doesn't have 64-bit integers? roTimeSpan.TotalMilliseconds() returns an integer, so surely it'll overflow long before that, or does the return value change to a double at some point?

[RokuMarkn]

Yeah I thought of that after I posted. Even if it does change to a double (I'm not sure if it does), you'll start losing precision making it less useful. So probably 2^31 ms is the practical limit even though internally it runs longer.

--Mark

[dev42]

First off, I want to make an app that someone is going to run for days at a time!

Secondly, my memory is fuzzy -- possibly because I wasn't a successful DOS video game programmer -- but isn't there an accepted work around for this type of thing?

Why wait for it to happen? Why not make your own wrapper function and reset the "marked" time storing in a double what you need?

OR for that matter, why not parse the system time? That should work unless the user time travels with their Roku...

peace & 42

[EnTerr]

"dev42" wrote:
Why wait for it to happen? Why not make your own wrapper function and reset the "marked" time storing in a double what you need?

Be-e-cause... Occam's razor?
There seems to be agreement roTimespan will cover periods of up to 24 days, so if not near that magnitude, use the it.

Certainly would be nice if the proper limit gets documented though (is it also true for fw3?).

[dev42]

"EnTerr" wrote:

"dev42" wrote:
Why wait for it to happen? Why not make your own wrapper function and reset the "marked" time storing in a double what you need?

Be-e-cause... Occam's razor?
There seems to be agreement roTimespan will cover periods of up to 24 days, so if not near that magnitude, use the it.

Certainly would be nice if the proper limit gets documented though (is it also true for fw3?).

I rem it from a movie... had to google/wikipedia it. 😛
per that, "I do not think it means what you think it means."
You are assuming it won't fail. My more complicated solution once tested will not fail. Assuming someone else programs it. :roll:

But since we're on the subject of assumptions, what happens to his program when the Roku in question does a system update? Are you sure it won't or is that an assumption. :?:

If it won't happen. Then what are the odds one would side-load a channel at the very moment the Roku was updating? But that'd be off-topic so I'll say I'm "hoping" it wasn't that cuz then it wouldn't be me. :oops: