The problem with this issue is not all are witnessing it, so very hard to track down the cause and replicate.

I’ll check tomorrow with Humax Towers, on progress identifying what triggers it.

I am also experiencing this problem since the ’49 update and it has got worse since the latest update. The only way to keep the schedule is to leave the box on 24/7.

grahamlthompson – 1 hour ago

I don’t have the box, but has anyone tried pulling the plug overnight ?

I don’t know about pulling the plug, pulling teeth may be easier.

It doesn’t lose the schedule, it simply doesn’t populate and display it when coming out of standby the next day.

There are some ingenious work arounds such as deleting a single channel, i.e. one of the many rubbish ones, which will force a rescan of the schedule, repopulate and display it.

Cold rebooting also solves the problem, so I’d imagine pulling the plug overnight would only result in the same cold reboot the following day.

It happens intermittently for some and not at all for others so only those users where it happens intermittently will have any insight as to causes. At first I though it may be a timing issue where the hard drive isn’t 100% ready when coming out of standby, but I believe even those with two boxes 500GB and 1TB haven’t seen a pattern.

However, a date change, as BlackGhost alluded to, when the box is in standby could also be the problem. i.e. if the box is still switched on and running after midnight or GMT then it handles the change of date and has no problem with the schedule. However, if the box goes into standby before midnight or GMT then when it comes out of standby it hangs on the schedule as the date is wrong.

This may explain the intermittent behaviour for some users where the box may or may not have been still on and running past midnight or recording during this time. We know the problem does not occur when leaving the box on and not letting it go into standby.

The problem doesn’t seem to happen afternoon or evening so it’s not length of time in standby. It seems to coincide with date change. Why this happens for some and not at all for others though simply adds to the confusion.

The trouble is it’s time consuming to figure out a pattern. It’d be interesting to set a recording to run through midnight/GMT and possibly at other times on other mights which can be easily deleted the next day just to see if a time or pattern can be pinned down. Maybe one of the users that are affected could set an out of hours recording or two.

I assume Humax don’t know the exact cause yet.

Still be interesting to remove the power before midnight and see what happens when it is restored next day on the first boot.

Barry – 33 minutes ago  » 

As promised I have asked questions at Humax Towers….

Can members who have the issue answer the following:

1. Do you use IP based services a lot – eg Netflix, YouTube etc.

2. Do the symptoms persist when using said IP services or disconnect from using said services.

Brief explanation as to why I ask…..

When cache on the browser is full after using IP services, device will restart browser to clear up the cache during standby.

This has reduced devices not coming out of standby and it was included in 1.01.49 (and also the beta releases).

In some cases, whilst restarting browser, units cannot read recording schedules from middleware, where the schedule is stored.

The problem is just reading the stored data, timers should still record as planned.

I’ll now try and replicate this using one of my units.

As outlined in previous posts, we have the problem and it was introduced by 1.01.49. That update did appear to address the “not coming out of standby when recording” issue.

We do not use Netflix/Youtube alot on the the 4000T (Chromecast stick is currently faster and easier), but I have noted the 4000T is sometimes very slow filling/updating the On Demand page. Presumably the catch-up programs on the guide (ie. left button from the guide) will also be using the buffer referred to?

Barry, before your post this morning, I was being to wonder whether this was a “phone home” related issue. I say that for three reasons

(a) I assume the catch-up programs details on the guide are downloaded from a remote (Humax?) server rather than received OTA – in the evenings when switching on the catch-up details are slower to load than a daytime switch on (current/future details tend to load in the same time frame whether evening or daytime);

(b) The slow filling/updating the On Demand page appears worse at peak evening viewing time; and

(c) It’s beginning to appear that we don’t get the missing schedule with a daytime switch on but are almost guaranteed to get one in the evening (say 7 – 7.45pm switch on).

I was going to try disconnnecting from the net (we’re wired, so it’s an easy job) to see whether this made any difference. Have just tried switching on (1pm) and get the full schedule so no point until this evening (and after the box has gone into full standby). In contrast, last evening 9 out of the 10 scheduled recordings we have set were missing from the schedule.

See also David’s post at https://myhumax.org/forum/topic/the-empty-schedule-problem/page/12#post-55925

If the 4000T is struggling to get details when phoning home on start up during peak times, could this be causing the buffer (or failed schedule load) issue?

Also, since deleting one of the many Freeview channels we don’t watch invariably causes the empty schedule to reload (even during peak hours in the evening), couldn’t the problem be solved by this “reload schedule on channel delete routine” being triggered as part of the start up routine.

I’d be interest to hear what Humax Towers say.

Barry – 3 hours ago  » 

As promised I have asked questions at Humax Towers….

Can members who have the issue answer the following:

1. Do you use IP based services a lot – eg Netflix, YouTube etc.

2. Do the symptoms persist when using said IP services or disconnect from using said services.

Brief explanation as to why I ask…..

When cache on the browser is full after using IP services, device will restart browser to clear up the cache during standby.

This has reduced devices not coming out of standby and it was included in 1.01.49 (and also the beta releases).

In some cases, whilst restarting browser, units cannot read recording schedules from middleware, where the schedule is stored.

The problem is just reading the stored data, timers should still record as planned.

I’ll now try and replicate this using one of my units.

Barry – thanks for this. Doesn’t sound at all related to me – I’ve only used IP services on a very small minority of the days it’s been happening.

Edit – I should add that as I’ve had the problem every night and never in the day it’s something that’s going on when the PVR is in standby between 02:30 and 09:00ish in my experience.