36 replies to this topic

[betacentauri]

Do you use WLAN and/or DHCP?

[s3n0]

Instead of working around it, it might be better to fix it. That begins with the question "why" it gets stuck.

 

Because (virtually) all of my boxes use it, for many years, and I've never seen this issue.

OK, please provide me with some development KIT for OpenPLi / Vu + device under Linux, and I'll step through the whole binary code in assembler or C language. Otherwise, I can't find out anything because I'm not an Enigma developer. I'm just a developer of Enigma plugins (Python language) .

 

This appears to be an incompatibility of the "ntpdate" binary. It is an ntpdate error that it does not report an error and that it remains "stuck". Probably not all possible error exceptions are debugged in the source code.

 

I can't figure out where the cause of the problem is because the debug-log in Enigma is poor in information (even when using DEBUG LVL 4 in the case of the OpenPLi image).

 

I have no tools and experience to be able to find bugs as fast as the OpenPLi development team .

 

 

FWIW my ViX boxes are running ntpdate (4.2.8p12-r0.5)

That's not how it works. A specific tool / service / command is always designed for a specific Linux (dependence on the Linux kernel, hardware drivers, libraries and modules and their configuration). If you move a binary file to another Enigma, it may not work. However, I risked this way and I tried a binary file from other Enigma distributions (OpenATV and VTi) for the MIPS/EL chipsets, but... of course... the first library error has occurred. I solved this unusually and not appropriately... by copying the whole library from another system :-). But then... another error arised, namely a problem with OpenSSL . So I left testing other "ntpdate" binaries. So transferring binary files is not a suitable solution - or possibly if from an older version of OpenPLi to a newer version of OpenPLi.

 

However, this is the work of the developers of the OpenPLi team. Now that developers know where the problem is, they can solve it very easily. Personally, I am not the developer of OpenPLi, as I have already written, so it would take me 5 hours, maybe 5 days and maybe 5 months to search for a 100% solution . However, anyone in the OpenPLi development team will solve this problem in 10 minutes, almost immediately.

 

 

 

[s3n0]

Do you use WLAN and/or DHCP?

 

Me ?

 

Of course yes, my home LAN network uses a DHCP service (Asus RT-AC66U_B1 router).

 

By the WLAN you mean a WiFi USB stick ? No... I do not use WiFi connection in my set-top box (Vu+ Solo SE V2). Cable connection only (RJ-45, built-in network card in the set-top box).

Edited by s3n0, 3 September 2020 - 16:29.

[WanWizard]

If you use the systemtime plugin, it asks you those questions, and based on the answers, inserts a delay (the sleep in the script) because ntpdate needs a working IP stack.
 
"sleep 0" only works if you use a static IP, or if you are lucky and have a very fast DHCP server. Chances are a "sleep 5" already fixes your problem.
 

OK, please provide me with some development KIT for OpenPLi / Vu + device under Linux, and I'll step through the whole binary code in assembler or C language.

 

There are some instructions here for Ubuntu and Redhat based linux distro's.

 

Basically install the packages for the host dependencies, clone our OpenEmbedded repository, and run a make to build the entire image, or a bitbake build command

bitbake ntpdate

to only build ntpdate and it's dependencies. See the bitbake manual for more info.

[ccs]

 

 

FWIW my ViX boxes are running ntpdate (4.2.8p12-r0.5)

That's not how it works. A specific tool / service / command is always designed for a specific Linux (dependence on the Linux kernel, hardware drivers, libraries and modules and their configuration). If you move a binary file to another Enigma, it may not work. 

 

 

I knew I shouldn't have given the version number, I was really just indicating that ntpdate is used in another image, not ntpd.

Edited by ccs, 3 September 2020 - 17:05.

[WanWizard]

The reason that ntpdate is used is that is it simpler and smaller, and a client-only, ntpd is a daemon that also has ntp server functionality. Which is overdone for one-shot time retrieval.

[s3n0]

If you use the systemtime plugin, it asks you those questions, and based on the answers, inserts a delay (the sleep in the script) because ntpdate needs a working IP stack.
 
"sleep 0" only works if you use a static IP, or if you are lucky and have a very fast DHCP server. Chances are a "sleep 5" already fixes your problem.

 

I also tried to set 15 seconds there. It didn't help. In my opinion, the network is not a problem. The network works very well on Vu+ and is initialized fast enough (maybe there is a good NIC-driver under Enigma, for Vu+ device, or maybe my metal wires in the LAN are good, ha ha).

 

I also tried the "-d" argument for "ntpdate". Unfortunately, it also does not provide much information. The process simply "hangs". We need to view the "ntpdate" source code or debugging through the code at runtime. Or run "ntpdate" in a debug mode, under development's KIT.

 

BTW, there is an "ntp-debug" package among the OpenPLi feed installation packages. What is it for ? Wouldn't it be possible to debug "ntpdate" with the tools in this package ? Or is it stupid idea ?

 

I won't try that development KIT anyway. Sorry. It's a long practice... it will take a long time to get a good practice. Then it will take time to find the cause of the problem. However, it looks like a binary file is stuck :-/. I'm old man for these things too. I already do such things for money or just as a hobby (that is, only if I am in a good mood and free time).

Edited by s3n0, 3 September 2020 - 18:01.

[mrvica]

we were using on the dbox2 a long time ago rdate (busybox)

 rdate -s time.fu-berlin.de

[WanWizard]

rdate should work too, indeed.

[s3n0]

Why is "ntpdate" also part of the "ntp" installation package ? Because after installing "ntp" package under OpenPLi (via Shell / opkg) the "ntpdate" package is also installed as well.

 

Then I have to solve it again manually - uninstall the "ntpdate" package:

opkg update && opkg remove ntpdate

Alternatively, remove the "ntpdate" symbolic line, via Shell:

update-rc.d -f ntpdate remove

In any case, as a temporary solution, it must be enough for me :-P.

[ccs]

Odd you're the only one with this problem, have you built your own image?

[s3n0]

LOL, how did you find out I was the only one problem ? This problem is related to updating the time over the Internet when for some reason you are not using satellite reception (IPTV only) and secondly the problem is only related to the "ntpdate" tool. If you set the time update via the Internet (NTP server) and if you have the entire "ntp" package installed, the problem may also manifest itself in you. Only possible with mips32el chipsets and with Vu+ Solo SE V2 devices. Unfortunately, more information requires tests. I can't do those because I don't have OpenPLi on all devices. I only have it on the "developer" set-top box, where I create plugins.

[WanWizard]

I'm not aware there is a dependency between ntp and ntpdate, but it could be the OE recipe defines it. It shouldn't however be a problem, as ntpdate is just a client which connects directly to the specified server.

 

And as mentioned before, I have it installed and running on all my boxes (including a slug-slow XP1000), as I only have one box connected to coax, and I've never had a problem with it (all boxes on DHCP, some also on wifi).

[ccs]

LOL, how did you find out I was the only one problem ? This problem is related to updating the time over the Internet when for some reason you are not using satellite reception (IPTV only) and secondly the problem is only related to the "ntpdate" tool. 

That's the first time you've mentioned satellite and/or IPTV, I'll leave it now, way over my head anyway.

[WanWizard]

You need it for any box without coax connected. All my boxes work via tuner fallback from my central VU+ Duo 4K, with 2 FBC modules (giving me 16 tuners).

[40H3X]

Thinking outside de box..., have you installed Bash? As by default OpenPLi has a stripped-down version of busybox and If you want more possibilities when working with the CLI you should install the "Bash" shell entering:

[s3n0]

Please guys, write the user's nick before your comments . Then I don't know who you're commenting on .