68 replies to this topic

[Rammy]

Hallo,

 

Ik gebruik Openpli 8.3-release met de laatste update van 2024-01-24.

Nu heb ik bemerkt dat de systeem klok van de VU+ circa 2 minuten achter loopt op mijn radiografisch bestuurde klokken welke ik heb.
De onderstaande setting worden er gebruikt:

MainMenu/Setup/System/Customize.Time synchronization method    auto
MainMenu/Setup/System/Customize.Time NTP Hostname        pool.ntp.org

Waar kan ik de DVD transponder vinden welke als tijdgever dienst doet?
Wat kan ik nog meer controleren om het probleem op te lossen.

Groet.

Rammy


 

[WanWizard]

Elke transponder heeft een timestamp. Het probleem met transponder time is dat ze niet allemaal op tijd lopen (sommige helemaal niet), en vooral terug gaan in de tijd is voor de box (om precies te zijn, voor de softcam), erg vervelend.

 

Aangezien de setting op "auto" staat, en de tijd niet correct is, lijkt me dat NTP bij jou niet werkt om e.o.a. reden, en de box terug valt op transponder tijd.

 

Ik zou dus om te beginnen de methode op "ntp" zetten, dan de box in deep standby zetten (uit), daarna de stroom er even af (schakelaar achterop), even geduld, en dan weer aan zetten.

 

Bljift de tijd op de box dan op 1970 staan, dan wordt het uitzoeken waarom ntp niet werkt. Krijg je wel de juiste tijd, dan lekker laten staan zo.

[cobus]

Hier bij mijn schoonouders hetzelfde geval (HD66SE) deze loopt ook ongeveer 2 minuten achter terwijl ik alle opties al geprobeerd heb ntp / transponder enz. (Ziggo)

Edited by cobus, 6 February 2024 - 14:57.

[Rammy]

Elke transponder heeft een timestamp. Het probleem met transponder time is dat ze niet allemaal op tijd lopen (sommige helemaal niet), en vooral terug gaan in de tijd is voor de box (om precies te zijn, voor de softcam), erg vervelend.

 

Aangezien de setting op "auto" staat, en de tijd niet correct is, lijkt me dat NTP bij jou niet werkt om e.o.a. reden, en de box terug valt op transponder tijd.

 

Ik zou dus om te beginnen de methode op "ntp" zetten, dan de box in deep standby zetten (uit), daarna de stroom er even af (schakelaar achterop), even geduld, en dan weer aan zetten.

 

Bljift de tijd op de box dan op 1970 staan, dan wordt het uitzoeken waarom ntp niet werkt. Krijg je wel de juiste tijd, dan lekker laten staan zo.

Ik heb je stappenplan uitgevoerd en heb nu weer de juiste tijd.

 

Dank voor je snelle reactie.

 

Groet.

 

Rammy

[WanWizard]

Met NTP KAN hij niet verkeerd lopen, NTP tijd is tot de microseconde correct. Hij kan hooguit even uit de pas lopen, NTP update maar eens per uur.

 

Als dat niet zo is, dan is er iets mis waardoor NTP niet werkt.

[WanWizard]

Vraagje (aan beiden): toevallig de box via wifi op het netwerk aangesloten ?

[cobus]

Nee bij mijn schoonouders niet.

[WanWizard]

In dat geval zie post #2 .

 

De kanttekening voor beiden: de optie "auto" werkt in 8.3 en 9.0 niet (zoals het zou moeten), in de zin dat ook als ntp gebruikt wordt, ook transponder tijd aan staat.

 

Dat probleem heb ik pas onlangs gefixt.

[Rammy]

Bij mij loopt de klok nog steeds 2 minuten achter.

Ik heb gisteren de Open-PLI 8.3 software ge-updated naar versie 2024-07-14.

Als ik de STB vanuit deep standby opstart dan wordt na booting de juiste tijd weergegeven.

De volgende dag echter loopt de klok weer 2 minuten achter, ook als ik 1 uur later de klok controleer.

Het lijkt er dus op de NTP update niet werkt.

 

 

Ik gebruik uitsluitend de NTP optie.

De STB is middels een vaste kabel verbonden met de router.

Ik schakel de router steeds uit als ik heb hem niet nodig heb, in de nacht dus.

 

Hoe kan dit probleem opgelost worden.

[WanWizard]

Of NTP werkt of niet kun je in de log terug vinden.

 

Op de commandline:

grep ntpdate /var/log/messages

of op de box, of via de TV, menu - info - uw ontvanger - gele knop - 5x rechts (denk ik).

 

Je moet dan iets zien als

Jul 14 18:30:00 sf8008 cron.info crond[1907]: USER root pid 1328 cmd /usr/bin/ntpdate-sync silent
Jul 14 18:30:06 sf8008 daemon.notice ntpdate[1337]: adjust time server 172.19.12.1 offset -0.025221 sec

 

[Rammy]

Als ik jouw commando, grep ntpdate /var/log/messages, laat uitvoeren dan krijg ik onderstaande reply te zien:

 

Jul 17 16:33:43 vu+ daemon.notice ntpdate[1305]: step time server 45.138.55.60 offset 146.142828 sec
Jul 17 17:30:00 vu+ cron.info crond[1350]: USER root pid 4370 cmd /usr/bin/ntpdate-sync silent
Jul 17 17:30:07 vu+ daemon.notice ntpdate[4375]: adjust time server 81.172.225.142 offset 0.031127 sec
Jul 17 18:30:00 vu+ cron.info crond[1350]: USER root pid 4407 cmd /usr/bin/ntpdate-sync silent
Jul 17 18:32:34 vu+ daemon.notice ntpdate[4412]: step time server 129.250.35.250 offset 147.016024 sec
Jul 17 19:30:00 vu+ cron.info crond[1350]: USER root pid 6445 cmd /usr/bin/ntpdate-sync silent
Jul 17 19:32:34 vu+ daemon.notice ntpdate[6450]: step time server 167.99.42.106 offset 147.036798 sec
Jul 17 20:30:00 vu+ cron.info crond[1350]: USER root pid 10013 cmd /usr/bin/ntpdate-sync silent
Jul 17 20:30:07 vu+ daemon.notice ntpdate[10018]: adjust time server 45.83.205.227 offset 0.034368 sec
Jul 17 21:30:00 vu+ cron.info crond[1350]: USER root pid 10041 cmd /usr/bin/ntpdate-sync silent
Jul 17 21:30:07 vu+ daemon.notice ntpdate[10046]: adjust time server 45.138.55.61 offset 0.017014 sec
Jul 17 22:30:00 vu+ cron.info crond[1350]: USER root pid 11314 cmd /usr/bin/ntpdate-sync silent
Jul 17 22:30:07 vu+ daemon.notice ntpdate[11319]: adjust time server 94.198.159.16 offset 0.025896 sec

 

De ntp server update werkt dus.

 

Naar mijn idee zou het terug vallen op de transponder timestamp alleen dan mogen gebeuren als de systeem tijd is ouder is dan de momentele transponder timestamp.

Dit zal in het algemeen alleen zo zijn bij een nieuwe installatie van het systeem daar er op dat moment nog geen actuele systeem tijd aanwezig zal zijn.

Indien er dus geen NTP functionaliteit aanwezig is zou de systeem tijd niet aangepast moeten worden naar de transponder tijd indien de systeem tijd van een recentere tijd is.

In een reply van 6 February 2024 - 20:06 meld je dat: 'de optie "auto" werkt in 8.3 en 9.0 niet (zoals het zou moeten), in de zin dat ook als ntp gebruikt wordt, ook transponder tijd aan staat. Dat probleem heb ik pas onlangs gefixt.'

 

Het lijkt er sterk op dat er nog steeds terug gevallen wordt op de transponder tijd ook als alleen de ntp optie aanstaat.

 

Zou je dit willen verifieren.

[WanWizard]

Dat zou best kunnen, zoals hierboven al vermeld zitten er allerlei bugs in 8.3-release vwb timekeeping.

 

Maar dat is een end-of-live release, dus daar gebeurd niks meer aan, in develop (wordt 9.1-release) is dit probleem geadresseerd.

 

Wellicht kun je dus develop eens flashen, en kijken of daar je probleem opgelost is?

[Rammy]

Ik ben terug gevallen op OpenPLI 8.3 omdat ik bij OpenPli 9.0 problemen had om de Bouquet file terug te zetten.

Hiervoor heb ik ook een draadje aangemaakt.

 

grep ntpdate /var/log/messages
Jul 17 16:33:43 vu+ daemon.notice ntpdate[1305]: step time server 45.138.55.60 offset 146.142828 sec
Jul 17 17:30:00 vu+ cron.info crond[1350]: USER root pid 4370 cmd /usr/bin/ntpdate-sync silent
Jul 17 17:30:07 vu+ daemon.notice ntpdate[4375]: adjust time server 81.172.225.142 offset 0.031127 sec
Jul 17 18:30:00 vu+ cron.info crond[1350]: USER root pid 4407 cmd /usr/bin/ntpdate-sync silent
Jul 17 18:32:34 vu+ daemon.notice ntpdate[4412]: step time server 129.250.35.250 offset 147.016024 sec
Jul 17 19:30:00 vu+ cron.info crond[1350]: USER root pid 6445 cmd /usr/bin/ntpdate-sync silent
Jul 17 19:32:34 vu+ daemon.notice ntpdate[6450]: step time server 167.99.42.106 offset 147.036798 sec
Jul 17 20:30:00 vu+ cron.info crond[1350]: USER root pid 10013 cmd /usr/bin/ntpdate-sync silent
Jul 17 20:30:07 vu+ daemon.notice ntpdate[10018]: adjust time server 45.83.205.227 offset 0.034368 sec
Jul 17 21:30:00 vu+ cron.info crond[1350]: USER root pid 10041 cmd /usr/bin/ntpdate-sync silent
Jul 17 21:30:07 vu+ daemon.notice ntpdate[10046]: adjust time server 45.138.55.61 offset 0.017014 sec
Jul 17 22:30:00 vu+ cron.info crond[1350]: USER root pid 11314 cmd /usr/bin/ntpdate-sync silent
Jul 17 22:30:07 vu+ daemon.notice ntpdate[11319]: adjust time server 94.198.159.16 offset 0.025896 sec
Jul 17 23:30:00 vu+ cron.info crond[1350]: USER root pid 13229 cmd /usr/bin/ntpdate-sync silent
Jul 17 23:30:07 vu+ daemon.notice ntpdate[13234]: adjust time server 81.172.225.142 offset 0.021962 sec
Jul 18 00:30:00 vu+ cron.info crond[1350]: USER root pid 15635 cmd /usr/bin/ntpdate-sync silent
Jul 18 00:30:07 vu+ daemon.notice ntpdate[15640]: adjust time server 45.138.55.62 offset 0.022702 sec
Jul 18 01:30:00 vu+ cron.info crond[1350]: USER root pid 17419 cmd /usr/bin/ntpdate-sync silent
Jul 18 01:30:07 vu+ daemon.notice ntpdate[17424]: adjust time server 45.138.55.61 offset 0.022277 sec
Jul 18 02:30:00 vu+ cron.info crond[1350]: USER root pid 17849 cmd /usr/bin/ntpdate-sync silent
Jul 18 02:30:16 vu+ daemon.err ntpdate[17854]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 18 03:30:00 vu+ cron.info crond[1350]: USER root pid 17874 cmd /usr/bin/ntpdate-sync silent
Jul 18 03:30:12 vu+ daemon.err ntpdate[17879]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 18 04:30:00 vu+ cron.info crond[1350]: USER root pid 17899 cmd /usr/bin/ntpdate-sync silent
Jul 18 04:30:12 vu+ daemon.err ntpdate[17904]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 18 05:30:00 vu+ cron.info crond[1350]: USER root pid 17923 cmd /usr/bin/ntpdate-sync silent
Jul 18 05:30:12 vu+ daemon.err ntpdate[17928]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 18 06:30:00 vu+ cron.info crond[1350]: USER root pid 17948 cmd /usr/bin/ntpdate-sync silent
Jul 18 06:30:12 vu+ daemon.err ntpdate[17953]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 18 07:30:00 vu+ cron.info crond[1350]: USER root pid 17972 cmd /usr/bin/ntpdate-sync silent
Jul 18 07:30:12 vu+ daemon.err ntpdate[17977]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 18 08:30:00 vu+ cron.info crond[1350]: USER root pid 17997 cmd /usr/bin/ntpdate-sync silent
Jul 18 08:30:12 vu+ daemon.err ntpdate[18002]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 18 09:30:00 vu+ cron.info crond[1350]: USER root pid 18022 cmd /usr/bin/ntpdate-sync silent
Jul 18 09:30:12 vu+ daemon.err ntpdate[18027]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 18 10:30:00 vu+ cron.info crond[1350]: USER root pid 18046 cmd /usr/bin/ntpdate-sync silent
Jul 18 10:30:12 vu+ daemon.err ntpdate[18051]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 18 11:30:00 vu+ cron.info crond[1350]: USER root pid 18071 cmd /usr/bin/ntpdate-sync silent
Jul 18 11:32:36 vu+ daemon.notice ntpdate[18076]: step time server 45.11.106.190 offset 149.324836 sec
Jul 18 12:30:00 vu+ cron.info crond[1350]: USER root pid 18096 cmd /usr/bin/ntpdate-sync silent
Jul 18 12:32:34 vu+ daemon.notice ntpdate[18101]: step time server 81.172.225.142 offset 148.031079 sec
Jul 18 13:26:43 vu+ daemon.notice ntpdate[18129]: step time server 129.250.35.251 offset 148.031234 sec
Jul 18 13:30:00 vu+ cron.info crond[1350]: USER root pid 18134 cmd /usr/bin/ntpdate-sync silent
Jul 18 13:30:06 vu+ daemon.notice ntpdate[18139]: adjust time server 45.159.204.28 offset 0.001382 sec


Ik heb wellicht toch een oplossing gevonden.
Op Jul 18 13:26:43 heb ik zelf via ssh command, . /usr/bin/ntpdate-sync silent, laten uitvoeren en dan wordt de klok aangepast aan de juiste tijd.
Zie hiervoor Jul 18 13:30:06

Maar hoe implementeer ik dit in een cron batch file welke regelmatig aangeroepen wordt.

Onderstaande code werkt helaas niet!

-----------------------------------------------------------------------------------
#!/bin/bash

#check for network connection
    if cut -d ' ' -f 1 <<<"$( hostname -I )"; then . /usr/bin/ntpdate-sync silent; fi
-----------------------------------------------------------------------------------

OpenPLI begrijpt 'hostname -I' niet.
Dit commando geeft bij Ubuntu het IP-adres uit welke de computer gekregen heeft.
Indien de computer dus geen IP-adres heeft is er ook geen LAN verbinding.

Hoe moet ik het script aanpassen zodat het wel gaat werken?

 

Edited by Rammy, 18 July 2024 - 13:12.

[40H3X]

Ik ben terug gevallen op OpenPLI 8.3 omdat ik bij OpenPli 9.0 problemen had om de Bouquet file terug te zetten.

Hiervoor heb ik ook een draadje aangemaakt.

 

• Waar staat dat draadje dan?
• Als je een autobackup hebt gemaakt voordat je overstapte en deze na het flashen restored, dan staat de zenderlijst ook weer terug zoals die was in 8.3
• Overigens had @WanWizard je het advies gegeven om naar Develop te gaan en niet naar 9.0!

[WanWizard]

Een STB is geen desktop, je vind er dus geen volledig linux OS op, daar is geen ruimte voor. Veel commando's ontbreken, of zijn flink uitgekleed om ruimte te besparen.

Jul 18 13:26:43 vu+ daemon.notice ntpdate[18129]: step time server 129.250.35.251 offset 148.031234 sec

is de output van ntpdate-silent, die staat al in cron. Dat is ook je probleem dan ook niet.

 

Er zit ook een enorme fluctuatie in, tot 19:30 heb je een fluctuatie van zo'n 140s per uur, daarna is het milliseconden, dan een tijd geen NTP mogelijk (router uit?), daarna weer in de 140s, tot 13:30, dan loopt de tijd weer correct.

[Rammy]

 

Ik ben terug gevallen op OpenPLI 8.3 omdat ik bij OpenPli 9.0 problemen had om de Bouquet file terug te zetten.

Hiervoor heb ik ook een draadje aangemaakt.

 

• Waar staat dat draadje dan?
• Als je een autobackup hebt gemaakt voordat je overstapte en deze na het flashen restored, dan staat de zenderlijst ook weer terug zoals die was in 8.3
• Overigens had @WanWizard je het advies gegeven om naar Develop te gaan en niet naar 9.0!

 

Ik heb hier het volgende draadje aan gewijd: https://forums.openp...terug-plaatsen/

[Rammy]

Een STB is geen desktop, je vind er dus geen volledig linux OS op, daar is geen ruimte voor. Veel commando's ontbreken, of zijn flink uitgekleed om ruimte te besparen.

Jul 18 13:26:43 vu+ daemon.notice ntpdate[18129]: step time server 129.250.35.251 offset 148.031234 sec

is de output van ntpdate-silent, die staat al in cron. Dat is ook je probleem dan ook niet.

 

Er zit ook een enorme fluctuatie in, tot 19:30 heb je een fluctuatie van zo'n 140s per uur, daarna is het milliseconden, dan een tijd geen NTP mogelijk (router uit?), daarna weer in de 140s, tot 13:30, dan loopt de tijd weer correct.

Op Jul 18 13:26:43 heb ik het comando, . /usr/bin/ntpdate-sync silent, laten uitvoeren. Dit had tot resultaat dat de klok de juiste tijd weergaf. Vandaar mijn voorzichtige conclusie.

 

Kan ik geen extra software op het systeem zetten waarmee ik de mogelijkheid krijg om te controleren of het systeem een IP adres heeft?

Hoe controleerd het systeem zelf of het verbonden is met een LAN netwerk?

[40H3X]

Je kunt in het about scherm je IP adres zien en ook onder netwerk instellingen.

Attached Files

•  uClan-Usytm-4K-Pro-OpenWebif.jpg   119.19KB   1 downloads

[Rammy]

Ja, dat is heel mooi maar ik zou deze instellingen in een bash file willen kunnen raadplegen.

 

Ik kan het ping commando gebruiken om te controleren of het systeem verbonden is met een LAN netwerk.

Ik kan echter geen cron commando gebruiken daar het systeem dit niet herkend hoewel het wel zelf cron script files ten uitvoer brengt.

Dus waar kan ik deze cron file's vinden om aan deze file mijn script file toe te voegen, waarmee het probleem dan opgelost zou moeten zijn.

 

Onderstaande script file heb ik tot nu toe:

 

-----------------------------------------------------------------------------------------------------------

#!/bin/bash

ip_gateway="192.168.188.1"

if ping -c 1 "${ip_gateway}" | grep -Eiq "errors"; then exit 0; fi        #exit, no LAN
/usr/bin/ntpdate-sync silent
 

-----------------------------------------------------------------------------------------------------------

 

Wie komt er met juiste oplossing?

[WanWizard]

Je blijft navelstaren.

 

Het probleem is niet dat NTP niet werkt, die werkt aangetoond wel, zie je eigen logs. Het probleem is dat ook transponder time nog aan staat, en die past bij de eerste de beste zap de tijd weer terug aan. Ook als je nog 30 cron jobs aan maakt.

 

En dat kun je alleen maar oplossen door niet meer te zappen naar transponders met foute tijd, of door de tijdinstelling op NTP te zetten (en niet op auto), door naar een develop image over te stappen, of te wachten tot OpenPLi 9.1.

 

Ik heb nog even gedacht aan de rotte clockfix van Oscam, maar volgens je log heb je periodes dat de klok prima loopt ( gokje, dan staat de box in standby en wordt er niet gezapt ).