73 replies to this topic

[Erik Slagter]

As WanWizard or more less suggests, it's futile to depend on the contents of the epg.dat file. Even if you system is correct, it may very well not be read at startup, either because enigma thinks it's corrupt or because it has only outdated entries. If you want epg, I suggest you use xmltv (EPGImport plugin) and configure it to always fetch the data after reboot.

[Dimitrij]

For info..

plugin EPGRefresh --> 'Automatic load period (in hours)' epg.dat

[antony23]

I already use EPGImport plugin to import epg... why i should fetch same data again at boot? I already have this data: epg.dat

 

EPGRefresh: automatic load period is not what i'm looking for! I want epg.dat loaded at boot.

 

Systemtime plugin: I don't use wifi, but ethernet. The problem is that enigma2 module loading epg.dat is called before systemtime plugin set the time. For this reason i set the time before enigma2 starts and epg load is done, and it works!

Edited by antony23, 6 September 2016 - 14:22.

[WanWizard]

It doesn't matter if you use wifi or not, it is just a delay you set to give the box time to setup a network connection before doing an ntp update. Which is your problem if I understand you correctly.

 

As said, I have never had a problem with importing the epg,dat in combination with the systemtime plugin, and I update / reboot my box every day, as it is an OpenPLi test box.

[antony23]

OK, so i test again systemtime plugin and report the result.

 

Thanks.

[WanWizard]

Just make sure the delay is set properly, you might have to try a few values before you find the right one.

 

What intriges me: how come your box has problems enabling it's fixed ethernet interface? It should be up and running long before Enigma starts...

[antony23]

Tried with systemtime plugin, but it doesn't work. It worked only first time.

At boot, i see first channel osd with wrong time, that is fixed 2-3 seconds later. But, at that point, i think epg module has been already called (so, no epg!).

 

With my trick, i'm sure ethernet interface is working before enigma starts. For this, imho, it works.

 

I don't know why etherent interface keep so much time to be working, i think the problem is the crappy et4000 box!

[WanWizard]

The "wifi" delay set in the systemtime plugin translates to a "sleep" before trying to run ntpdate or ntpd, so that suggests you didn't make the sleep period long enough to make sure it works everytime.

[antony23]

I tried with 30s. Do you think it is not enough?

Are you sure systemplugin is executed before or stop the execution of epg.dat loading? This is the key...

[WanWizard]

I don't know how crap the network of your 4000 is.

 

The plugin creates /etc/init.d/ntpdate, in my case containing

#!/bin/sh

sleep 5

[ -x usr/sbin/ntpd ] && /usr/sbin/ntpd -dnqp pool.ntp.org

exit 0

As it is an init script, whatever you define in the plugin will only become active after the next reboot.

 

BTW: this is only used when "Sync NTP cold start" is enabled.

[ringlord]

Sorry to react to this old thread but since yesterday the date and time is off and I cannot set it

 

openpli 4 vuduo

 

vuduo login: root

root@vuduo:~# date

Sat Feb 15 07:22:26 CET 2020

 

root@vuduo:~# /usr/sbin/ntpd -dnqp pool.ntp.org

ntpd: sending query to 85.88.55.5

ntpd: reply from 85.88.55.5: offset:-91373361.448665 delay:0.009792 status:0x24 strat:2 refid:0x41e6bec1 rootdelay:0.000900 reach:0x01

ntpd: sending query to 85.88.55.5

ntpd: reply from 85.88.55.5: offset:-91373361.448761 delay:0.009898 status:0x24 strat:2 refid:0x41e6bec1 rootdelay:0.000900 reach:0x03

ntpd: sending query to 85.88.55.5

ntpd: reply from 85.88.55.5: offset:-91373361.448720 delay:0.009795 status:0x24 strat:2 refid:0x41e6bec1 rootdelay:0.000900 reach:0x07

ntpd: sending query to 85.88.55.5

ntpd: reply from 85.88.55.5: offset:-91373361.448683 delay:0.010306 status:0x24 strat:2 refid:0x41e6bec1 rootdelay:0.000900 reach:0x0f

ntpd: sending query to 85.88.55.5

ntpd: reply from 85.88.55.5: offset:-91373361.448704 delay:0.010318 status:0x24 strat:2 refid:0x41e6bec1 rootdelay:0.000900 reach:0x1f

ntpd: setting time to 2017-03-24 17:53:30.588726 (offset -91373361.448704s)

 

root@vuduo:~# date

Sat Feb 15 07:23:04 CET 2020

 

Edited by ringlord, 24 March 2017 - 17:59.

[ringlord]

I flashed to image openpli-4.0-beta-vuduo-20170316_usb.zip  and problem is solved...

[funradio]

make it easy..

 

past "ntpd -q -p pool.ntp.org" on emu stcritp which use before "exit 0"

[WanWizard]

Recent oscam running that you installed yourself?

 

It will block changes to the date unless it is compiled or started with that option disabled.