173 replies to this topic

[littlesat]

ntp will not adjust the clock immediately but it will gradually adjust it, over a large timespan.

Where can I find this information as here it directly adjust it?

[Erik Slagter]

It depends on how much the time is off.

[WanWizard]

Exactly. 

 

If it is really off, even the "date" command on the commandline doesn't work, so no point looking into ntp tools, as that is not looking at the root cause.

[Pr2]

Very strange your conclusion, power off a STB with no clock at all ( I think the Zgemma H5 for example) then start it up.

It will have a very old date and time then issue an NTP and the date and time will be set properly.

[WanWizard]

What are you referring to?

 

I don't think anyone has said you can't set the time after a cold boot, on the contrary, that is the only time you CAN set it.

[MiLo]

...
You could get an I2C RTC chip, with integrated battery, and connect it to any I2C inside the box (tuner slot?). That'd be more cost effective, but not very generic...

That would cost you about $ 0.20 but it has a few drawbacks:
- most of them are SOIC or smaller

Yep, that's the only real problem. You could get a chinese PCB manufacturer to create some kind of break-out board for a few cents.

- how are you going to adress them from user space, if the driver do not share the bus with user space (kernel i2c subsystem)

User space I2C is not needed (and should be avoided anyway), there are perfectly fine drivers for most I2C clock chips. This also means the kernel will fetch the time from the RTC as soon as it is available, usually before userspace starts.

- possible address conflicts with tuners or other native hardware

Just look at /sys/bus/i2c/ and see what's in use. Chances of conflict are very small, and usually you can set the last address bits by pin strapping. And there are multiple I2C buses available, which also helps avoiding conflicts.
And RTC chips do not use any bandwidth at all, so you can share them with anything.

[MiLo]

But that's all very theoretical. A simple GUI entry (e.g. near the timezone selection) to reset the time to the currently tuned transponder time would be a more productive approach I think.

[WanWizard]

Functionality that Dimitrij has already built into the systemtime plugin.

[Erik Slagter]

Just look at /sys/bus/i2c/ and see what's in use. Chances of conflict are very small, and usually you can set the last address bits by pin strapping. And there are multiple I2C buses available, which also helps avoiding conflicts.
And RTC chips do not use any bandwidth at all, so you can share them with anything.

You are assuming here that the internal i2c buses are exported to the kernel and user space. I very much doubt that. A driver developer has no interest in making the i2c bus available to user space.

 

Address conflicts are more likely than you'd think, because large ranges of the just 7 bits of addresses are reserved. And would you know which addresses are used by tuners and other internal hardware?

[mrvica]

for Raspberry PI there are RTC´s around, means the software can be used straight away on an armhf box, we just need someone to do the beta testing
https://thepihut.com...ur-raspberry-pi
https://raspberry.ti...t-raspberry-pi/

[theparasol]

If "init 4" doesn't work, than means it is not code in Enigma that refuses the clock change. Interesting...

 

If you use a clockfix enabled oscam binary the cause is 100% oscam.

if at startup your time is "not set" the clockfixed oscam will wait and once NTP or a transponder has set the time to something that is younger than oscam build time oscam will maintain the time.

 

Some transponders are consciously tinkering with the timesignal to frustrate cardsharing but as usual watching legitimately with a card in reader of your opensource box is affected too.

 

To "fix" the time:

 

Kill oscam, fix your time and start it again.

 

Or just use whatever you want to fix your time correctly and use a non clockfix enabled oscam binary but dont complain about non working ratelimiters, black picture, bad cw cache, disconnected clients and more reported issues I already have forgotten about.

 

Yes there were several attempts in the past to start using CLOCK_MONOTONIC but they all failed.

I guess lack of good coders willing to work for free on the oscam project...

Edited by theparasol, 29 December 2017 - 20:58.

[WanWizard]

Ah. Now that is something new, and I have to say highly unexpected.

 

Is there a config value to disable this behaviour? This needs to be addressed and fixed at the linux level, not in any user binary (and that includes Enigma).

[theparasol]

Is there a config value to disable this behaviour? This needs to be addressed and fixed at the linux level, not in any user binary (and that includes Enigma).

 

http://www.streamboa...trunk/config.sh

 

default: CONFIG_CLOCKFIX=y

 

All oscam builds with clockfix have "Clockfix with realtime clock: yes" (you can check in webif -> files -> oscam-version)

 

To have it removed: this can only be done at compiletime... so before compiling the oscam bin flip it to CONFIG_CLOCKFIX=n

 

Is it a unusual and dirty thing: yes, I agree but hey it works and fixes things (even on my setup hence the default on)

If anyone can improve the oscam code the right way just do it. But be warned you will enter a fucing rabbithole.

 

BTW I'm more than happy to commit a sound and clean solution to fix this properly in oscam but only problem is it needs to be made first...

Till then the second best option is in effect and all complains are ignored.

 

Ignore mode on again...

Edited by theparasol, 29 December 2017 - 21:41.

[WanWizard]

Ok, so it's a compile time switch... Hmm...

 

My point is that this shouldn't be in Oscam at all. Linux should make sure the time is correct for all userspace apps, those apps should not interfere with stuff the OS is tasked to do.

 

So it should not be altered, it should be removed.

[theparasol]

Why OpenPli not make it configurable in the BSP layer? So every manufacturer that integrated a correctly ticking RTC should be able to remove all timefixes in the image by some kill switch.

That way we can close another neverending story now (and in the future) and we can all blame the manufacturers instead and use our precious spare time to improve the working of the image itself.

[WanWizard]

Can don't have write access to the BSP's, so we can't make any changes. And I doubt manufacturers want to get involved with Oscam...

[theparasol]

Read carefully:

 

Remove all time hacks in enigma. In a specific feed for that model receiver you can deliver a clockfix disabled oscam.

Or not, thats up to the OpenPli team. I dont care.

 

If you wish you all may even blame my notorious bad coding skills: I can live with that

[WanWizard]

If it is up to me, we remove all hacks, everyone of them. We don't need hacks, we need proper solutions (which I know is not easy, hence this thread).

 

I don't see why there should be any blame involved. The last time I wrote a C program was over 30 years ago, I'm not saying anything about coding skills.

 

I'm only saying a solution for an invalid clock should not be implemented in CCcam. Or in Enigma.

[theparasol]

I'm only saying a solution for an invalid clock should not be implemented in CCcam. Or in Enigma.

 

Yes, the "just saying" phrase: So better discuss it within the OpenPli team. Compile oscam the way the team members wants to have it.

[Abu Baniaz]

Is it possible to apply the 120 second restriction only if time sync is set to use transponder time?