23 replies to this topic

[s3n0]

BTW, today I tried it and it also does not work (OpenATV image). If the set time is less than the current time, it can not be changed. On the contrary, it works. So if I want to move time forward, it's possible if I want to shift back time, so it's not possible. It's just about some BUG .

[WanWizard]

STB hardware doesn't have an RTC. So the box always starts up at time 0 (the unix epoch).

 

The system clock will be set from transponder time from the first transponder tuned into. After that, the time is updated on each zap, unless the transponder time from the new channel has a delta that is too large, in which case the time update will be rejected. So it is important to always start the box (cold start!) on a known good transponder. If you don't, it starts of with the incorrect time, and will never correct it, as the correct time will be rejected due to the delta.

 

The system clock runs in software, not in hardware, so you should be able to set it manually using "date", or automatically using an ntp based solution. In both cases, you need to disable transponder time, otherwise every zap will update the time again.

 

The easiest way to do that is using the Systemtime plugin, it has all options needed to configure ntp and disable transponder time.

[esgraon]

Thank you guys!

 

I usually use only the deep standby – so can my record timers always work.

After a few days the current time is less than the system time (app. 40 sec per week).

Of course the cold start always helps, but when I'm not home.

Sure, “margin before recording” solved the problem.

It's just that I thought that sync works in both directions.

Now I understand that I was wrong.

[s3n0]

Oh, OK, All right.

 

I personally do not use the time synchronization via the transponder - I have disabled this feature. :-P I prefer to synchronize the time over the internet. This saves time faster even if the box is rebooted. For sure, I have already linked through RunLevel3 my own user's "autostart.sh" Bash-script (containing the command: ntpdate pool.ntp.org).

However, this is not related to the problem. Anyway, after restarting the box or after a long time using the box, I have no problem with the deviation of the real time clock.