Clock has not changed today. Is this being addressed by engineers!?
Windsorlad
Member Posts: 1 ✭
in Community
Is this being addressed?
1
Windsorlad
Member Posts: 1 ✭
Windsorlad
Member Posts: 1 ✭
Windsorlad
Member Posts: 1 ✭
Comments
This has just been confirmed to me via their support on Twitter.
Best not roll your eyes; that the EPG is behind as well is a relief, as it means that the programmes you choose to record still get recorded correctly.
To know where the problem is requires knowing how this changeover is managed; there is almost certainly a time server somewhere that is involved, but these all run at UTP, and then a time zone offset is applied somewhere, possibly centrally at TalkTalk, possibly on every individual box (erk!)
On the minicomputer I programmed to do the time change, as it wasn’t built in to the OS, a weekly jobstream run on Saturdays had a task that would check if the current day was the day before a GMT/BST change - in this case the last Sunday in March, as has been the case for years into the past - and launch another job to run at the change point and alter the time zone in use - the system clock itself remained unchanged. The same two jobs would reverse things at the end of October.
We were lucky the OS could handle this, though not as lucky as the Unix boxes where the changeover is built into the OS, but much luckier than the IBMs, where it took the teams most of Sunday to knife and fork it 😛
I’ve no idea why something that has worked perfectly before, about 20 times or more, for TalkTalk boxes, hasn’t worked this time, and yet Humax boxes are OK.
I do hope somebody is going to tell us, in the fullness of time.
But is it TT boxes or boxes that use the TT YouView service? Hence my question above. Are there any Human boxes that use the TT YouView service?
Retail boxes still pick up generic updates, not TalkTalk ones.
Be interested to know though if anyone has a TalkTalk box and moved away so on a different provider, if they have this issue.
We are aware of the issue with the Time on some boxes currently. We are working with TalkTalk to resolve this issue as soon as possible.
Thank you for your patience whilst we investigate.
Kind Regards
Shaun
YouView boxes make a number of different accesses; to know exactly what, you would have to use Wireshark, and then try and trace where the IP accesses are going.
Certainly, updates are always based on the box model, regardless of the ISP in use; a moment’s thought will tell you why this has to be, but it doesn’t tell you where the update is coming from, only which update it needs to be.
Likewise, which apps appear is based on the box model; Prime won’t vanish off a BT box used on another ISP.
The UI ‘skin’ is based on the ISP; BT, TalkTalk or Other (generic); maybe there is an additional one for PlusNet? But though the skin is based on the ISP detected, it may not come from the ISP; the skin data is small enough for the box to hold all the skins quite easily, and just serve up the desired one. But I don’t know which of these arrangements is in place, nor how to tell.
The EPG content is based on the ISP; my boxes don’t just adopt the BT skin because I am with BT, all the BT TV channels appear as well, even though I am not with BT.
Though whether the EPG entries come from a BT server on a BT IP address, or from a BT server hosted by YouView, or from a YouView server populated by BT, I don’t know.
And the only ways I can think of to determine the answers here are to figure out what logically must be the case, or can’t possibly be the case; or to use black box error determination, where, when something goes wrong, you get a further insight into what might be the case from the way the error changes things.
As here, where the issue seems to be associated with TalkTalk boxes, but not TalkTalk as the ISP, and we would like to know if it affects TalkTalk boxes on a different ISP. My guess is yes, but maybe I’m wrong. As this is something that I thought would depend on the ISP, and as Humax boxes on TalkTalk are unaffected, it clearly doesn’t.
Clearly, it’s something for TalkTalk to fix, no doubt aided by YouView developers, but it will be interesting to see if this can be fixed centrally, or if it needs an emergency update rollout to TalkTalk boxes. Which would tell us something about where the issue is.
Thats an interesting deduction, but is it correct?
Imagine we had an old, unsmart, TV, doesn’t even know what the internet is.
How is it going to know when GMT switches to BST? How is it even going to know what day it is, to make that switch?
And yet they all did, and did it correctly.
So I think it’s going to get its date and time from the Freeview signal - has to, in fact.
Which then leads us to the conjecture that the TalkTalk box must be ignoring, or overriding, the Freeview date/time. My guess is ignoring; YouView boxes must be taking their date and time from some YouView, or ISP, server.
And not simply the ISP the box is connected to, or Humax boxes on TalkTalk ISP would have this issue. So this strengthens my guess that TalkTalk boxes on any ISP would have this issue, though it’s still not conclusive.
I wonder if some kind soul at YouView would like to try this, @Shaun F?
Same issue with epg time being incorrect, noticed that yesterday. May be unrelated, but today box wouldn't start up, stuck on youview loading screen. Tried all the fixes, eventually maintenance reset retaining saved programmes worked. Just hoping it doesn't struggle to start every time now.
Highly relevant!
Is it still an hour out, after the reset?
If so, do your catchup apps work? (Also being asked of anyone whose box is still an hour out).
This makes me think an update may be forthcoming.
They haven't said what the issue was, and probably won't as companies often do not want to broadcast issues.
I had a temporary problem years ago with my T1000, where it took the date to be January 1st 2012, when it was actually December 2012. Or something like that; I don’t think the details matter. But because I was away, it ran like that for several days, clock and date advancing normally. But it never looked at the correct time again from anywhere, until I rebooted it.
(And yes, all the programmes I had set to series record, before the date glitch, were indeed picked up OK 😛)
So what would you predict my Humax box would do, if I turned it off and did a cold start? And what would you class as a cold start? As it can’t be anything that would have the box trying to reach an internet server, and failing.
@meyou2
OK, this is much more subtle than we are giving it credit for. Go back before the Sunday 1am move to BST, and all the prior programmes are shown with GMT times.
There is no 1 am Sunday on the Guide ; it skips straight to 2am where the 1am would otherwise be, and then carries on forward in BST.
Unplugging the Ethernet cable, then the power, waiting, and then putting the power back, 12am Sunday going forward is exactly the same as with the internet connected; no 1 am, straight to 2am, but all the programme information showing as unavailable, as this comes over the internet. Until I put the Ethernet cable back, at which the EPG spontaneously repopulates.
Youview are scheduling a software update overnight to resolve this issue. TV boxes need to remain powered on/in standby and be connected to your router to enable the software to install automatically.
We'd like to apologise for any inconvenience caused by this and will continue to update you here with more information.
TalkTalk's call centres must have had an interesting day
I don’t see YouView confirming that it was their error, not TalkTalk’s?
If your box hasn’t yet updated, can you try this rather odd advice from Google Bard, and see if it works?
“My TalkTalk YouView box hasn’t changed to BST
I understand that your TalkTalk YouView box hasn't changed to BST. This is a known issue that TalkTalk is working to resolve. In the meantime, you can try the following to manually update your box:
If this doesn't work, you can contact TalkTalk customer support for further assistance.”