Non-Custom Protection from OTA

Black Hole

May contain traces of nut
Summary: Over-the-air (OTA) firmware updates can have an adverse effect on your HD/HDR-FOX, not only adding new features you might not want but also introducing bugs that were not there before. You might want to delay updating your firmware until the community has assessed its pros and cons. Custom Firmware (CF) users definitely don't want OTAs - it would wipe out the custom firmware until a new version is ready or the HD/HDR-FOX is returned to its previous state. CF users should also note that the disable-ota package is not 100% effective in all circumstances. The solution is a Reminder set to cover the OTA search time which make the Humax busy with a higher priority task. To cut to the chase see footnote ***.

Update 03/03/2014: The disable-ota custom firmware package now automatically adds the reminder to the schedule if it does not exist. This behaviour can be de-selected in the settings if it is not required by the user.

I guess a manual daily recording schedule from say 4:15AM to 4:45AM would prevent OTA's
I can confirm this worked! Thank you. However, an even better method that I've tried is to set a daily reminder from 4:25am to 4:35am, which has the exact same effect without clogging up my box with unwanted recordings.

This is for all the non-modders disinclined to install the Custom Firmware, but also offers the prospect of eliminating one package from the custom overhead.

Why would the non-mod community want to prevent an Over-The-Air firmware update? Until recently there was no compelling reason, each new OTA release was a significant improvement on the last. This was true up to 1.02.20, and 1.02.27 (significantly) corrects the DLNA client 4GB bug*, but it (and subsequent revisions) also comes with a huge irritation: forced retunes.

So what's the problem with a forced retune? Easy, retunes delete your recording schedule, so here's the scenario: you are going on holiday for a couple of weeks, you've been through the programme guide and set up all the recordings you want, and you have the daily 20-minute insurance wake-up set to make sure the EPG is kept up-to-date (for more information see HERE - click). The day after you leave, the box does an OTA scan and updates itself to 1.02.28 (or whatever). It then gets a prompt from the broadcast network that a channel scan would be in order, so the next time it fully wakes up a message appears saying (to the effect) "you need a retune, shall I go ahead now?" - you're not there to see it but with 1.02.27+ installed it goes ahead and retunes by default. The consequence is a wiped recording schedule and no recordings made to watch when you get home (the point about being away is that if you were at home at least you would be able to put things right fairly quickly). Further, the retune will be an automatic full scan, which may not pick up the right transmitter and give you multiple channels (services that appear in the 800s) - which we know confuses the recording schedule as well.

It has been mooted that if a retune is deemed necessary, then subsequent recordings would fail if you did not retune anyway. This is not so. Some retunes (recent examples 19/09/2012 and 17/10/2012) only shuffle the LCNs - Logical Channel Numbers - which identify the service to you as being the number you type in to the handset to get a particular station (eg "11" = Pick TV - at the moment), the number which is displayed on screen, and the number the broadcasters use to advertise their service. The recorder does not use LCNs internally, setting up a recording or actually changing channel uses a Service ID which the user does not normally see, and this does not change with the retune. Thus, after an LCN-only shuffle, not having done a retune has absolutely no effect on the Humax other than stick with the old LCNs. Thus it is better for no retune to happen unattended, and your recordings to carry on as normal (probably), than for a retune to sneak in unnoticed and kill your schedule - in which case no recordings will happen at all, guaranteed.

Now, there are several confounding factors here. Firstly, it is not at all likely that an unattended retune will occur while the Humax is recording from stand-by. Even when it wakes up for the OTA search it probably won't be awake enough to be flashing up retune messages on the screen, which I think is the determining factor - would it be displaying on the TV screen (if the TV was on to see it). Consequently you should be immune from a retune while you are away were it not for another Humax bug - its inability to track series recordings beyond the first unattended week if you use padding (not AR**) and if you do not set a periodic 20-minute wake-up to keep the EPG refreshed. The problem is that during that wake-up it might just take it into its head to do a retune.

So what's the answer? If you are running the custom software, you are probably already aware of disable-ota (which eliminates the scheduled OTA search), and disable-dso (which eliminates the retune nag). disable-dso is not sufficient alone: an OTA wipes out the CF until you reinstate it, disabling disable-dso and thus leaving you vulnerable for that period, therefore you need to control firmware updates yourself by download and manual install and using disable-ota to eliminate the OTA check. Users of disable-dso should also be aware that there is still a slim theoretical opportunity for a retune to slip in regardless. However, if you do not run custom (or even if you do) there are still measures you can take.

Extending Ezra's and JimmyRotten's suggestions (above) I am trialling the idea of setting a scheduled reminder*** daily at 4.20-4.40am, in place of my previous EPG refresh (which used to avoid the OTA search), and so far I have not had 1.02.28 forced onto me during the recent spate of OTA transmissions. There are still a few tests I want to make before I announce discovery of the God particle, but it's looking good (see next post). Why use a reminder rather than an actual recording? Well, firstly an actual recording will leave an unwanted file to be deleted each time (custom users could record it straight to the delete bin). More seriously, a manual timed recording does not have AR characteristics so although it would defeat OTA, it would not serve the dual function of ensuring EPG update.

In summary:
  • 1.02.20 (and previous) nags for a retune (when the broadcast network deems appropriate) but doesn't go ahead by default;
  • 1.02.27+ nags for a retune and goes ahead if you don't stop it;
  • Unattended retunes are a very bad idea - they delete your recording schedule;
  • Automatic update is preventable by moving your EPG refresh reminder to 4.20am, or use the disable-ota custom package;
  • If you are already on 1.02.27+ you can restore 1.02.20 by download;
  • If you wish to keep 1.02.27+ but wish to eliminate retune nags, use the disable-dso custom package.
  • disable-dso is also useful with 1.02.20, because although the retune nag would not actually result in a retune if ignored, it won't go away completely until you allow one.
* When using the Humax (HD- or HDR-FOX T2) to stream content from elsewhere on the home network by DLNA, it treats anything beyond the 4GB point in the media file as if it were end-of-file, ie playback ends at that point and it cannot be wound past. This has been corrected in 1.02.27+ (1.02.27 was never broadcast as an OTA).

** AR users also need a periodic wake-up to protect from the (much less likely but still possible) scenario where a series recording has a gap of more than a week. If there are no other recordings scheduled in the mean time, the next programme event is outside the span of the EPG and will not therefore be added to the recording schedule. Without another wake-up the next (and any subsequent) programme will not be recorded. By making your insurance wake-up an actual recording using AR (not manual), you will eliminate the retune risk by it not being a full wake-up - but also be littered with unwanted recording files.

*** How to set a Reminder into the schedule manually: Guide >> Yellow >> New Reservation then set Channel to whatever you want it to power up on next boot, Date = tomorrow, Start Time = 04:20, End Time = 04:40, Repeat = Daily, Mode = Reminder.
I am "pleased" to report my experiment was a complete success. After a couple of weeks with disable-ota uninstalled and replaced with the 0420-0440 reminder (during which time there have been several opportunities to be OTAed) my HDR remained resolutely on 1.02.27. Yesterday I deleted the reminder, and today I have 1.02.28 (and dead CF... soon to be returned to 1.02.20!).

It would be valuable to get confirmation of these results by somebody else of course, but I say it's good to go.

As noted previously, this daily reminder serves the dual purpose of keeping the EPG refreshed. We have also had a report of boxes updating despite disable-ota being installed, and this can happen if it is not given a chance to run by being rebooted regularly (it is likely the boxes in question were on at the time of the OTA and therefore didn't boot even for that). The reminder should work even in those circumstances.
One minor issue with the scheduled reminder solution is that it seems to set the favourite channels back to the default "TV" list. It's a bit tedious having to change it back every evening when SWMBO asks where all those funny channels in the EPG have come from, and where have the HD channels gone...
Catch-22. If you're trying to preserve 1.02.20, it will reset to the default list. The issue is fixed in 1.02.28 - but you don't want that!
What are the remaining disadvantages of 1.02.28 with disable-dso? The Internet radio has been removed from the portal entirely (or is it still accessible via one of the custom portal packages?)

I could write a package to assert the favourites list on every boot if it would be useful.
I think ejstubbs is a committed non-modder, although the offer of forcing the favourites list (an extension to the force channel?) every boot might turn his head.

Aside from the obvious, the main problem with .28 is audio description - and the problem with .20 is the 4GB bug. .27 (running on my HD-FOX) is infinitely more reliable booting than .20 was, and of course without an aerial OTA and DSO are not an issue.

I believe it is the case that, even modded, disable-dso can't be 100% reliable under all circumstances. My HDR is stopping on .20 until there is a compelling update (complete with disable-ota and OTA-defeat back-up - I don't use favourites).