[solved] Wrong system time, how to get the correct time again

  • At dm7080 (latest exp image) I have since a couple of days the wrong system time: it is 6 minutes ahead. I changed to diff. satellites to eliminate the possibility of a wrong tp time. I also stopped E2 and changed /etc/enigma2/settings to: "config.misc.useTransponderTime=false" but after restarting E2 and even after a complete reboot I get again the same wrong systemtime. Also in network settings (menu key) I set ntpautoupdate to manual (maybe the same effect as changing E2 manually) but again wrong system time.

    I also tried to change the systemtime with the command date MMDDHHmm and for 1 second the systemtime is ok but than the systemtime at my dm7080 is again wrong.

    I checked at my dm900 (with also latest exp image) and there everything is ok. Very weird, but what can I do....

    [Later] I also tried the plugin dvbtime, but did not help either.

    Edited 2 times, last by ni_hao ().

  • 1. Switch to a transponder with correct time.
    2. Go to StandBy (Deep StandBy), cut the Power Line for about 30sec. (the RealTimeClock lose the Time.)
    3. Power on, and everything its ok. ;)

    >> Wir Schweizer haben die Uhren, aber keine Zeit ! <<

  • did not know that, thanks Swiss-MAD. Now I can not reproduce it, but I'd like to know what causes the wrong system time and ... when "config.misc.useTransponderTime" is set to true (which is default) the time should be ok after switching to many different transponders and even to 3 different satellites.

    Unfortunately the system time was not ok, so there must be somewhere something wrong. And - as written - it was not only at my dm7080. At the same time I checked at my dm900 and there is was ok. When it happens again maybe a bootlog will give some directions.

  • E2 accept always a new transponder time, when the difference to the actual time its smaller than 120 seconds.
    So it's possible to add up some small time differences, up to over 120 seconds. After this accept E2 not the right time, because the difference is grater than 120 sec.

    >> Wir Schweizer haben die Uhren, aber keine Zeit ! <<

  • Ah thx again. Actually you are saying that updating to tp time is for E2 limited to < 120 seconds. That declares why the system time was not updated here because the time difference was appr. 420 seconds. That might be extraordinary but is there any reason for this (short) limitation in E2?

  • Time is only updated when the difference is >120 s. You can easily see that in the log. There is a very speaking message.


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • Yes but question was/is what the reason for that limitation is. Would be nice if there is no limitation or a configurable limitation time

  • Here is the last public version of the corresponding DMM code: https://github.com/OpenPLi/eni…/lib/dvb/dvbtime.cpp#L350
    There it says:

    // with stored correction calced time difference is lower 2 min
    // this don't help when a transponder have a clock running to slow or to fast
    // then its better to have a DM7020 with always running RTC

    I assume that the exact number of 2 minutes is just a random guess. But the main idea behind this is that you do not want to adjust the time with every transponder change as there will allways be a deviation of a few seconds.
    But the overall assumption seems to be, that the transponder time is to be trusted and if the locally stored time is way off, then the local time must be wrong. While this is probably true for the transponders on Astra 19.2E, you seem to have some transponders with a totally corrupt time.

    However, as the linked code is very old, this might have changed meanwhile. Most notably OE 2.5 now supports NTP (Network Time Protocol) and therefore also adds an internet time, if available. So this might be another solution to your problem.

    so long

  • It's like m0rphU wrote: it does not make sense to constantly update the time. And 2 mins seems to be a limit defined randomly. In my opinion it does not make sense to offer a user setable time. This is something a user should never be confrknted with. Again agreeing with what m0rphU said: use ntp if your transponders are that much off.


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • it is already inside every DreamOS image - press the Menu Button when in Network setup ...

  • Once again, I think this issue is still reproducible in some cases :( when time was broken on bad transponder and set to 2h from the future
    Even with ntp enabled and switch to correct time transponder I got:

    maj 31 01:11:08 dm520 enigma2[1682]: [eDVBLocalTimeHandler] Receiver time is 'Thu May 31 01:11:08 2018'
    maj 31 01:11:08 dm520 enigma2[1682]: [eDVBLocalTimeHandler] Transponder time is 'Wed May 30 23:08:17 2018'
    maj 31 01:11:08 dm520 enigma2[1682]: [eDVBLocalTimeHandler] diff is -7371
    maj 31 01:11:08 dm520 enigma2[1682]: [eDVBLocalTimeHandler] no correction found... store calced correction(7371)
    maj 31 01:11:08 dm520 enigma2[1682]: [eDVBLocalTimeHandler] not changed

    Is this really accepted action? Time shouldn't be fixed?
    I doubt only switch off of DM should be solution.