Example/receiver.rs doesn't work for me

[jergon-s]

Hi I'm jaehyuk from S.Korea.

Thanks to this open source, I could progressed my project eaisly, but I faced something weired recently.
My application(streaming server with srt and rust) server always stops at specific time when I test this code below.

1. cargo run --example receiver
2. cargo run --example sender

After 4295 ~ 4300 seconds(or so), approximately 1hour 11minutes later, receiver stops.
I tested over 10 times, but always got the same result.

Please somebody help me.
At least I hope you would test example code.
Don't forget, you should stream over 4300 seconds.

I'm looking forward to your any answer.
Thanks.

// execute sender
% cargo run --example sender
    Finished dev [unoptimized + debuginfo] target(s) in 0.10s
     Running `target/debug/examples/sender`
Sent 711010 packets

// execute receiver
examples % cargo run --example receiver
    Finished dev [unoptimized + debuginfo] target(s) in 2.72s
     Running `/Users/me/test/srt-rs/target/debug/examples/receiver`
Received SystemTime { tv_sec: 1611567922, tv_nsec: 399080000 }  <<----- start point
Received SystemTime { tv_sec: 1611572217, tv_nsec: 305890000 } <<------ stop pooint. it took 4295 sec, and stopped.

[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?

[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.

[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 :/