12 replies to this topic

[mark_hopley]

Hi

Is it possible to get a dm500 running openpli to keep time/date via ntp over net?

[joseb]

I have just bought an et5000, and installed package ntp, ntp-bin and ntpdate.
(opkg install ntp ntp-bin ntpdate)
I expect they will be available for a DM500 too, but I don't know for sure.

You might want to look in /etc/ntp.conf, the file delivered in the feed
lets ntp synchronize with ntp.pool.org, you might want to change that
to the time server of your provider.

Strictly speaking, you don't need ntp-bin or ntpdate.

Ntpdate offers you the possibility to set the system time
(from the shell prompt) from a time server, when ntp is not running,
like this:

ntpdate time.planet.nl

ntpd is configured in such a way that it will eventually synchronize
even if your system is an hour off, but for initial setup it's a nice to have.

ntp-bin provides several tools, the handiest being ntpq, which gives you the
possibility to check the functioning of you ntp daemon, like so:

root@et5000:~#ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.0.1 213.75.60.246 2 u 46 256 377 0.212 1.916 1.130

The little star in front of the timeserver says it's synchronized to a timeserver, and the 377 under reach says
connectivity to it is flawless. Google for more info, it's quite hefty.

Anyway, with me, it works. Good luck!

[joseb]

Caution: in the ntp.conf that comes with the ntp package, the localhost is supplied as a timeserver
of last resort. The idea is that ntp will continue running if connection to the server on the internet is lost.
If this happens regularly for prolonged periods of time, then running ntp is not a good idea.

# Using local hardware clock as fallback
server 127.127.1.0 <--------------- comment out by placing a # in front of it
fudge 127.127.1.0 stratum 14 <--------------- this too

Reasons to comment it out:

- ntp will not synchronize correctly with the actual real timeserver, for reasons unknown to me
- if localhost had such a reliable clock, why have it synchronize to a timeserver in the first place?
- general advice is not to do that, unless localhost is being synchronized by another source.(Google ntp localhost server)

I'm not sure who is maintaining this package, so hopefully it will reach this person, for the time being
comment the 2 lines mentioning server 127.127.0.1 out by putting a hash before it.

Edited by joseb, 30 September 2011 - 17:49.

[Amatøren]

I have a DM500+ just set up as a mediaplayer to my server. No LNB connection. Is it possible to sync the time/date to another DM500+ tha has a LNB connection and then has the right time and date?

Edited by Amatøren, 30 September 2011 - 19:01.

[theparasol]

I have a DM500+ just set up as a mediaplayer to my server. No LNB connection. Is it possible to sync the time/date to another DM500+ tha has a LNB connection and then has the right time and date?

If your box has a valid lan connection and internet access use an internet ntp server as mentioned in the previous replies.
It's much easier to setup. If you have to user another box inside your lan you have to config a ntp time server on that box. That's much harder to accomplish.

[joseb]

As the parasol said, ntp does not work over an lnb, it has little to do with tv reception, more with computers.
Just install the ntp package on one both of your boxes, and follow instructions in this thread: install optional
packages and edit /etc/ntp.conf.

[Amatøren]

I was thinking of a script to read the time and date from another Dreambox by the LAN connection and then set the time and date on the Dreambox that the script is running on.

[joseb]

NTP does that too, and will keep the time accurate during the whole time the box is on.

[joseb]

Can someone knowledgable of how enigma2 works confirm that putting

config.misc.useTransponderTime=false

in /etc/enigma2/settings will actually stop enigma2 setting the time based
on the time of the satellite transponder gives?

I found this setting in mytest.py, and I tried it. It definitely looks good, I have
now a 100 times smaller offset from the time server than I used to have, but that might
be luck, and I wouldn't mind actually knowing what I'm doing :-).

[pieterg]

yes, that's what the setting is for.

Note however that e2 doesn't like it very much, if it gets an external systemtime.
Some things (timers, epg) might still think they are running on transpondertime.

[joseb]

Thanks.
I sometimes found 1-2 second 'jumps' when monitoring ntp time, and thought it might
be caused by enigma2 synchronizing to a transponder, and it certainly looks that way.

I tried to find references in the forums as to how this might cause conflicts or what
would go wrong, but I couldn't find anything clear except this one:

http://openpli.org/f...h__1#entry53846

Could you elaborate a bit on how this would cause problems, and what these problems would be?

[pieterg]

Could you elaborate a bit on how this would cause problems, and what these problems would be?

1. e2 relies on it's own timekeeping for sleep/delay/timers.
When it syncs on transponder time (and the time is different from the current time), it works around this by applying an offset.
When the systemtime is set by an external source, e2 will suffer from clock skew. Timers might never run out, or trigger too early.
2. epg event times *might* be considered relative to transponder time, rather than system time. I'm not sure whether this is actually the case.

[joseb]

Obviously there are reasons for e2 to even consider the possibility
that at the same moment it's not the same time. Reasons I can think of
are an unset system clock or a transponder time that is way off.
Both would indicate error somewhere.
Well... I'll see what happens. Thanks for the info.