9 replies to this topic

[Satpal]

This afternoon I switched the box on from stand-by. I noticed that the time was wrong, it was set 1 hour ahead. The timezone was still set correctly. Changing channels didn't help. After a reboot this problem was cured but then I noticed another weird thing: most of my timers were showing a starting time of October 2016 instead of February 2016. I tried editing them via the Webif but that didn't work.

Any ideas what could have caused this? The only thing apart from the usual was copying 500 GB from an external hdd onto the internal disk but I fail to see a connection there.

I recall that once before my timers were messed up similarly and I still don't know what went wrong then or now.

[Pr2]

Which box, brand and model?

Are you sure that it is from standby and not from deep standby?

 

The time of the STB is taken from the TV channel where it starts, so if you were on a TV channel that use a different timezone the time will be wrong.

But I think that the time is take only when it is lost (so for sure after a reboot) and I don't think that waking up from a normal standby will trigger a new time settings.

 

If you watch channels from different timezone it is for sure better to use a NTP server time than the DVB time.

[Satpal]

This time it happened on a ET 10000, not sure on which box the timers were messed up last time. I'm aware of the problems on certain transponders (especially on 16E) that have a wrong time. But those were usually a few minutes off and were corrected by zapping to a good transponder. This time the time was off by exactly one hour and couldn't be corrected without a reboot. Normally my boxes never go into deep stand-by and this one was up for at least two or three days.

I was once involved in a discussion here about the system time problem where I suggested that the time could (or should) be taken from a specified transponder chosen by the user (possibly the start up channel) as in other images I know. But in the meantime everything was working fine for months or years with different boxes (VU Duo and Solo2, ET 5000 and 9000) all of them running Openpli 4.

 

The only idea concerning the timers I can come up with that this kind of problem seems to occur after I edit timers via the OpenWebif.

[Pr2]

Hi,

You can also defined a default channel to start you STB in OpenPLi.

In the channel list press Menu and select it as startup service so your STB will always "wake up" on the same channel.

[Satpal]

I'm aware of this option, I use it on all my boxes.

 

Today the same thing happened again. All recurring timers were set to the date of October 25th 2016 or later (depending on the day of week). System date was set to this date, too, + 1 hour (summer time?). This time I hadn't been using the OpenWebif, though, so it wasn't the culprit.

[Satpal]

Finally I seem to have found the problem. It's a combination of the lousy ET10000 tuners that need a few seconds to tune into certain transponders and the way Enigma2 (or Openpli?) reads the transponder data in this scenario.

 

Due to the storms in the last few days my dish had been slightly moved and since then the transponder 11.662 V on Hotbird was sometimes working after a few seconds and sometimes not. When it finally started to work the data received from this transponder might have been corrupted. Mostly the date was set to October 2016, today it also happened that it was set to December 2018 or May 2016.

 

I'm mostly bothered and baffled by two things:

 

1. The wrong date and time don't change after that anymore until reboot.

2. The timers are corrupted and set to the wrong start date and time.

[Pr2]

Point 1 is normal otherwise the time will change when you zap to a channel from another timezone and this is not the expected behavior.

Can you image somebody with a motorised dish or a big multisat that will have the time of his box changing when zapping to other countries channels?

So yes you are supposed to reboot your box on a TV channel from your local time.

 

Point 2: if you use a wrong dish pointing antenna you cannot blame the system if it received a wrong data, if there is no checksum broadcasted with the time then there is no way for the STB to detect the wrong time.

 

If you have such problem, then use NTP instead of "LNB" time.

[Satpal]

I'm not talking about different timezones, I'm talking about tranponders that transmit a wrong time that differs mostly a few minutes from the actual standard time for this timezone. Of course the box then adjusts the time according to the transponder time; that's why there was plenty of talk about this kind of problem before. Btw, if the time would in fact not change by zapping to another transponder we wouldn't be talking about this now as the corrupted data obviously changes the system time. I do have several multisat dishes including a motorised dish, btw.

 

I don't blame the system for receiving the wrong data (I also don't blame myself because my dish was slightly off, there can be plenty of reasons why reception could suddenly deteriorate and the box should still work then), but I don't understand why the correct time isn't restored on the next good transponder and why the timers are affected this way. I guess the starting times for the timers is calculated from a certain starting day. But after the timer being stored, why does this starting day still needs changing is what I don't really get.

 

But I suppose this is a rather rare problem that probably only applies to those Samsung tuners in the ET10000 and the Mutant 2400.

[Pr2]

How do you want a box to know what is the right time?

 

When the box start it totally lost its time and date and it is the signal that send this information, so the box start it must trust the time it receives.

Later on if there is a time difference why should the box know that this time is better than the first one it gets?

 

You want a good time for sure when box start, use NTP (Network Time Protocol) that's the only reliable time that you can get.

[Satpal]

Of course the box starts with a correct time (Channel 1: ARD Das Erste). After zapping to this transponder the problem occurs.