[disable-ota / disable-dso] Taking Back Control!

No...
Thus, when using tunefix-update, it is desirable that auto-retunes are actively prevented - ie use of disable-dso is strongly recommended, otherwise tunefix-update is more-or-less pointless.
Pointless? :eek: I wouldn't quite say that.
DSO events are fairly uncommon - say once every couple of years or so. There are many uses for tunefix-update a lot more often than that.
The tunefix-update package must, itself, be kept up-to-date to be able to do its job, and that (at the moment, until and unless an alternative update mechanism is provided) implies the use of the auto-update package to keep all the user's custom firmware packages updated.
As has been pointed out, this is now wrong. I think the best thing to do with that paragraph is strike it from the record.
Which is where post #48 came from. :D
But Dave Ja Vu is on #79. :whistling:
 
Pointless? :eek: I wouldn't quite say that.
DSO events are fairly uncommon - say once every couple of years or so. There are many uses for tunefix-update a lot more often than that.
That's not what I meant and I don't think that's what I wrote. tunefix-update bypasses the general aggravation of a DSO event, and if a DSO event were allowed to get through it would nullify the effect of tunefix-update on that occasion. I remain where I stand: anyone using tunefix-update should also have disable-dso installed, and preferably RTS enabled as well.

As has been pointed out, this is now wrong. I think the best thing to do with that paragraph is strike it from the record.
The paragraph wasn't wrong as I knew it, and anyone without auto-update installed and therefore potentially an out-of-date tunefix-update needs to update it manually before they get the benefit of its own auto-update mechanism (that I want to know more about before I write about it).
 
Now you know why I'm confused.:frantic:
I'l revisit and see if I can 'get it' this time round ('cause I've forgotten already. Now where did I put that goldfish?).
 
I remain where I stand: anyone using tunefix-update should also have disable-dso installed, and preferably RTS enabled as well.
I don't disagree. But that's not how I read it first time through.
You could also chuck a note about epgfix into the mix.
Now where did I put that goldfish?
It's probably stuck in your ear and you've forgotten about it.
Oh, that's a Babel fish. Probably the budget version then from Humax that they never quite got right.
 
So easy to understand that you have had to have a few goes at it?:devilish: Now I don't feel so bad about asking.:D


I switched off disable-ota and deleted it from the schedule. I then switched it back on but had to reboot to get it back into the schedule so how does RTS help there?
 
I switched off disable-ota and deleted it from the schedule. I then switched it back on but had to reboot to get it back into the schedule so how does RTS help there?
No idea what you're talking about. The OTA search is added to the schedule by the Humax standard firmware, whenever it likes. Using disable-ota to remove the OTA search requires a reboot or RTS.

So easy to understand that you have had to have a few goes at it?:devilish: Now I don't feel so bad about asking.:D
The sigh was because I had to reiterate all that.
 
I'm fed up with trying to get this sorted in my head ATM. I'll go and watch a bit of Coro or some other brain numbing programme and return to thinking about this tomorrow.
 
I'm fed up with trying to get this sorted in my head ATM. I'll go and watch a bit of Coro or some other brain numbing programme and return to thinking about this tomorrow.
It is a bit tricky:
The OTA search is added to the schedule by the Humax standard firmware, whenever it likes.
So Humax stick an entry in periodically to do an OTA check.
Using disable-ota to remove the OTA search requires a reboot or RTS.
The CFW can remove the OTA check from the schedule, but only at boot time unless you have RTS installed (which gets round the boot time limitation for changing the schedule).
 
A scheduled reminder spanning 0430 can be used to prevent an OTA search occurring, although admittedly that makes the unit wake up too. This defends against the circumstance that an OTA search slips through despite disable-ota being installed, as described in the previous paragraph. The consequence of an unwanted OTA search is that if it finds a firmware update it could over-write the custom firmware. If there are certain to be no further OTA updates, this fall-back defence is not necessary.

It is now certain that that there will be no further OTA updates so the reminder paragraph could now be deleted from BH's guidance (in april for absolute security)
 
The CFW can remove the OTA check from the schedule, but only at boot time unless you have RTS installed (which gets round the boot time limitation for changing the schedule).
The CFW could use RTS to remove OTA events but it won't happen automatically - do we know if disable-OTA package has been made RTS compliant?
Given that the search can no longer do any damage would it be worth the effort?
 
When you ask disable-ota to insert a reminder (or whatever it does), you need a reboot to get it into the schedule (unless I didn't wait long enough).

Is it the 'reminder' that 'does the business' of removing the Humax search, or is it something else?
 
I thought disable-ota and disable-dso had been made RTS-aware, but I could be wrong. If not, I will have to rethink and a lot of previous writing will have been in error.
 
[sigh]
And you wonder why I'm confused.:frantic::duel::roflmao:

Let me know when you have got it right please. In the mean time, I won't bother and go and watch Corrie (not).
[/sigh]
 
Back
Top