Black Hole
May contain traces of nut
I don't know yet. Will update when I do.So how does that affect your earlier post, if at all BH?
I don't know yet. Will update when I do.So how does that affect your earlier post, if at all BH?
Especially when posting 'news'. It's sods law that someone has beaten you to it.Oops... !! I should have scanned the messages a bit further back
No...
Pointless? I wouldn't quite say that.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.
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 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.
But Dave Ja Vu is on #79.Which is where post #48 came from.
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.Pointless? 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 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).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.
I don't disagree. But that's not how I read it first time through.I remain where I stand: anyone using tunefix-update should also have disable-dso installed, and preferably RTS enabled as well.
It's probably stuck in your ear and you've forgotten about it.Now where did I put that goldfish?
I'm not familiar with that one - I'll look into it.You could also chuck a note about epgfix into the mix.
So easy to understand that you have had to have a few goes at it? Now I don't feel so bad about asking.<sigh>
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.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?
The sigh was because I had to reiterate all that.So easy to understand that you have had to have a few goes at it? Now I don't feel so bad about asking.
It is a bit tricky: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.
So Humax stick an entry in periodically to do an OTA check.The OTA search is added to the schedule by the Humax standard firmware, whenever it likes.
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).Using disable-ota to remove the OTA search requires a reboot or RTS.
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.
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?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).