Example/receiver.rs doesn't work for me about srt-rs

[russelltg]

This looks like timestamp rollover, which hasn't been tested very much. I'll add a test for it (one that just simulates a connecting being open for that long). Someone else is welcome to take this but it's complex, so reach out to me.

[russelltg]

I think this is fixed now. I haven't run a receiver for a long period of time but my synthetic test now passes that didn't before.

Was an issue with timestamp rollover, as expected, but not the issue I assumed it was! Big thanks to @dholroyd for providing some info that lead to the fix.

[jergon-s]

Always 4295 sec.

I think that a variable declared by 'u32' is appecting.
As you know, max value of u32 is 4294967295. And if we assume the value is used as "micro second", that means exact 4295 sec.

So .. my guess is

1. there is a u32 value.
2. the value means micro second.
3. No. 2 means that MAX of the value is 4295 sec.
4. somewhere in the core, the process is always stopped by this max value 4295.

How about my guess?

[dholroyd]

Thanks @russelltg! My tests are able to run for more than 2^32 ticks now 🎉

Looks like #39 is revealed as the next limit to my test stream's uptime.

[russelltg]

6 hour testing time......fantastic :/